Newsgroup: it.lavoro.professioni.webmaster
Titolo: Database multilingua: come lo strutturate?

Ciao a tutti,
ho un dubbio sulla struttura di un db (mysql) per un sito multilingua:
attualmente sviluppo siti multilingua includendo il file della lingua
dopo aver selezionato la lingua di navigazione.
Nessun problema fin qui.
Ma mi inceppo sempre quando devo lavorare sui contenuti del db, nelle
varie lingue.
Qual'e' il metodo miglior per progettare un db multilingua?
Nel mio esempio ho un db di 4.500 prodotti; immagino che ogni prodotto
abbia un ID lingua; per cui se ci sono 5 lingue, ci saranno 5 record
per lo stesso prodotto, uno per lingua. Questo ha anche il vantaggio
di non avere limiti di lingua, ma si crea un db piuttosto voluminoso.
Es. 4.500 prodotti moltiplicati per tot lingue...
E' giusto cosi'?
Voi come vi organizzate?
Oppure, conoscete un buon testo per documentarsi sull'argomento?
Vi ringrazio in anticipo per la collaborazione.
Ciao
tony

 E' giusto cosi'?
In linea di massima e' una delle possibili soluzioni.
Puoi anche decidere di creare una tabella di dettaglio (relazione 1 a
molti) nella quale inserisci solamente i campi che richiedono la
traduzione (es. nome, descrizione, optional etc.). In questo modo non
duplichi quei dati che sarebbero duplicati (es. prezzo, dimensioni
etc.).
-- 
Vuoi distribuire il tuo sito web su CD/DVD?
Prova 
http://www.dwebpro.com/
Vuoi diventare un esperto analista PHP/MySQL?
Vieni a fare uno stage con noi: 
http://www.creativepark.it/stage/

 E' giusto cosi'?
No.
La tabella dei prodotti deve contenere i prodotti e dati relativi, non 
le loro traduzioni.
Quelle le metti in un'apposita tabella contenente solo i campi che vanno 
effettivamente tradotti.
In questo modo se devi cambiare il valore di un campo lo cambi solo in 
un punto, non in n (dove n = numero di lingue presenti).
Alternativa č creare una tabella di traduzione dove indichi elemento, 
suo id, sua traduzione, lingua di traduzione (es.: 'articoli', '123', 
'matita', 'it'). Lato applicativo ti fai poi una funzione che carica la 
traduzione necessaria nel contesto (es. per tradurre i menů, le 
categorie articolo, le note).
Cosě puoi tradurre tutto, non solo articoli o elementi specifici, ma ti 
trovi un tabellone cospicuo (seppur solo di quattro colonne).
Ciao,
Paolo

 (seppur solo di quattro colonne).
Lo svantaggio di questa soluzione e' che per estrarre anche solo un
record con gli "elementi" gia' tradotti serve una query di una
lunghezza crescente al crescere del numero di campi (con join etc).


 lunghezza crescente al crescere del numero di campi (con join etc).
Vero, ma di solito se si usa "il tabellone" si lavora lato applicativo, 
non SQL, usando ad esempio un tag o una funzione specifica nella pagina.
Ciao,
Paolo

 specifica nella pagina.
Intendi dire che per ogni elemento della pagina che va tradotto (es.
nome prodotto, descrizione, bottone compra etc.) richiami una funzione
che effettua una query sul database ed estrae il valore richiesto?
Nel caso di tony, in una pagina col motore di ricerca dove vengono
visualizzati 10 risultati per pagina (nome e descrizione del prodotto),
dovrebbero essere effettuate 20 query diverse solo per i risultati, su
una tabella di oltre 22.000 record. Se non si implementa un sistema di
caching per il database, basta un numero limitato di client concorrenti
per far "sedere" il database server.
Con il sistema della tabella separata per i soli dati da tradurre (una
tabella diversa per ogni tabella che richiede la traduzione), per la
pagina di ricerca e' sufficiente una sola query.


 varie lingue.
Allora, come Docebo abbiamo trasferito tutte le lingue in DB per 
questioni di editing diretto e altre cosucce ... all'inizio un bagno di 
sangue, in particolare sull'encoding dei caratteri.
Fai molta attenzione, simulazioni, esportazioni importazioni, dump e 
restore di DB ... è più complicato di quello che sembra :-)
Cla
-- 
http://www.docebo.com
 [Docebo - The open source e-learning company]
http://claudioerba.blogspot.com
 [My Blog]
Molto sulle mie, quadrato, incazzoso, tremendo, insopportabile (Non sono 
eterno, prendete appunti)

 pagina di ricerca e' sufficiente una sola query.
Sicuramente è il sistema migliore, tant'è vero che è quello che gli ho 
suggerito anch'io. L'altra era una alternativa.
Ciao,
Paolo

 query.
In questo caso il problema sara' la quantita' di memoria richiesta per
caricare il dizionario ed i cicli di CPU necessari per farlo (es.
carica tutte le descrizioni in inglese di 4.500).


 'matita', 'it').
Perché non una relazione 
Descrizione(id,inglese,francese,tedesco,lappone,normanno) con id chiave 
esterna?

 carica tutte le descrizioni in inglese di 4.500).
Suvvia, non diciamo assurdità.
Prova a fare due conti (anche prendendo descrizioni estese, di 2-3000 
caratteri per articolo) e vedrai che l'occupazione di memoria è un 
decimo di quella occupata da un qualsiasi web server o anche solo da 
applicativi come firefox o simili.
In questo istante ho thunderbird che mi occupa 61Mb e un'applicazione 
web in python, con precaricati in due dizionari circa 150mila elementi, 
che ne occupa 12 (non dei soli dizionari, ovviamente, di tutta 
l'applicazione).
Il caricamento all'avvio è praticamente istantaneo (2-3 secondi su un pc 
non proprio nuovo: un xp1800 con 1Gb di Ram) partendo da db, di poche 
decine di secondi partendo da file.
Questo senza contare che raramente si carica tutto in memoria, esistono 
apposta paginazione, pattern strutturali, e via dicendo.
Inoltre, ripeto, questa non era la soluzione proposta, era 
un'*alternativa* (comoda in casi specifici) a puro scopo informativo.
Ciao,
Paolo

 esterna?
Dici seriamente?

 esistono apposta paginazione, pattern strutturali, e via dicendo.
Certo, pero' cosi' devi iniziare a inserire dei filtri per permettere
all'applicazione di identificare quali elementi caricare dal database,
ossia devi iniziare a rendere la query piu' complessa (es. solo gli
elementi "prodotti" con "ID = 1, 2, 3, 4, 5, 6" e "lingua = en"). Piu'
e' complesso l'SQL, piu' il database impiega a fare il parsing ed a
caricarlo, sempre per ogni richiesta HTTP e per ogni client.
Una soluzione come questa non e' scalabile, l'occupazione della memoria
aumenta in modo lineare con l'aumento degli utenti cosi' come il carico
della CPU.


 Dici seriamente?
Sě, a parte i termini (sto studiando Basi di Dati), perché non una 
tabella a parte con le descrizioni in una riga unica?
Sbaglio o mi sei sembrato sorpreso?
Se sta pensando di avere descrizioni degli articoli (mi sembrava che 
fosse il punto cruciale) in un certo numero di lingue credo che questo 
numero rimanga invariato cambiando articolo, cioč non hai 
"temperamatite" in italiano e francese e "gomma da disegno" in italiano 
e tedesco, se hai scelto di presentarti ai mercati tedesco e francese 
prima o poi dovrai pur tradurre le descrizioni di tutti gli articoli. 
Nel caso una descrizione venga lasciata NULL la scelta ricade su quella 
italiana, o magari inglese.

 Sbaglio o mi sei sembrato sorpreso?
No, non sbagli. Ma non tanto per la domanda in sé: l'uso di lingue un 
po' "particolari" (diciamo non diffuse) mi aveva fatto sorgere il dubbio 
che fosse una battuta... ;)
Tornando alla domanda iniziale: non è una buona soluzione mettere le
lingue nelle colonne perché questo implica dover modificare la base
dati ogni volta che si aggiunge/toglie una lingua (con relative
modifiche sulle query e applicativo).
E' buona norma evitare di modificare la struttura del database in corso 
d'opera: la si progetta all'inizio e (almeno idealmente) la si cambia 
solo per serie necessità impreviste.
Aggiungere una lingua non rientra in questa categoria, è un'attività 
"comune".
Inoltre gestendo adeguatamente le chiavi primarie e gli indici si 
risparmia spazio e numero di campi da gestire.
Ciao,
Paolo

 della CPU.
Seguendo il tuo ragionamento sì, peccato che sia completamente sbagliato.
Non a caso praticamente tutti gli app server usano questo sistema per 
caricare i dati "comuni".
Inutile ribadire per la terza volta che non era la soluzione al problema 
(quella era la prima parte della risposta), ma un'*alternativa* utile in 
casi particolari, giusto?
Ciao,
Paolo

 "comune".
La ritenevo invece un evento "raro", al limite uno si porta avanti 
riservandosi lo spazio per 10 lingue, mi sembra che i database odierni 
gestiscano bene lo spazio con i valori NULL.

 sistema per caricare i dati "comuni".
E' sbagliato solo se tony parlava di utilizzare un application server e
non una piattaforma diversa (es. PHP/MySQL).


 non una piattaforma diversa (es. PHP/MySQL).
Non per fare il pignolo ma tony non ha mai parlato di PHP.
A parte questo, il PHP Cookbook (e non è l'unico, anzi) consiglia di 
usare un dizionario (array) per gestire l'internazionalizzazione.
Sistema usato anche da parecchi framework (symphony, ad esempio), visto 
che anche mod_php è un application server, per quanto basilare (gestisce 
sessioni, connessioni al db, transazioni, componenti server side, etc.).
Inoltre il caricamento in memoria di oggetti condivisi non è 
caratteristica esclusiva degli app server.
Quindi l'unico caso in cui si potrebbe applicare il tuo discorso è avere 
un http server che faccia solo ed esclusivamente da "eco": riceve la 
chiamata, elabora atomicamente i dati e reinvia il risultato.
Non so se esista (meglio: se sia usato) qualcosa del genere, fuori dai 
laboratori di informatica delle scuole.
Ciao,
Paolo

 gestiscano bene lo spazio con i valori NULL.
Non che sia una cosa folle (esempi in giro sicuramente ne trovi. Trovi 
anche molto di peggio... ;) ), ma i database relazionali sono nati 
proprio per evitare di dover gestire dati inutili.
Inoltre fissando un limitato numero di lingue nel giorno (fortunato) in 
cui l'applicazione fosse così diffusa da richiedere una traduzione in 
più ti attireresti le ire di tutti gli analisti e sviluppatori del 
progetto :)
Ciao,
Paolo
P.S.: le lingue riconosciute sono diverse migliaia (
www.sil.org/iso639-3/
)

 genere, fuori dai laboratori di informatica delle scuole.
Mai programmato in ambiente LAMP? 
Mai sviluppato un CGI (in Perl od altro linguaggio)?
Mai provato ASP?
Solo 3 esempi di situazioni in cui la soluzione proposta non e'
scalabile in termini di memoria utilizzata, carico della CPU e
performance.


 [...]
Manlio Perillo

 performance.
Magari spiega perché e cita dei casi reali: le discussioni sul sesso 
degli angeli le lascio a chi ha tempo da dedicarci.
Soprattutto perché se ti prendessi la briga di aprire google, cercare 
"internationalization [tecnologia a scelta]" vedresti che praticamente 
*tutti* (J2EE: JBoss e Tomcat, Ruby on rails, Django, svariati framework 
PHP, la "globalizzazione" di .Net) utilizzano questo metodo per le 
traduzioni applicative (_diverso il discorso quando si devono tradurre 
contenuti specifici, come i prodotti dell'OP, ma lì la risposta è gia 
stata data da tempo_).
Tra l'altro neanche partendo da database ma da semplici file di properties.
Risparmieresti (e faresti risparmiare) tempo ed eviteresti figuracce.
Ciao,
Paolo

 Per le traduzioni i dati sono immutabili, quindi non vedo problemi.
Rileggi tutto il tread. 
Il problema e' caricare in memoria ad ogni richiesta HTTP, per ogni
client, la traduzione in 5 linghe di 4500 prodotti, sia in termini di
memoria occupata con piu' client concorrenti, di performance e di
carico della CPU.


 figuracce.
Rileggiti il primo post di questo thread ed indicami un framwork PHP
(Java, Ruby etc.) che suggerisca l'utilizzo di file di properties per
la traduzione delle descrizioni di un catalogo di 4.500 prodotti.


 della CPU.
Si, lo avevo letto.
In questo caso io metterei le traduzioni nel database, se usi un database 
per memorizzare i dati dei prodotti.
Ad esempio
table prodotti {
    id,
    slug,
    descrizione -- nella lingua di default
    ...
}
table l10n_prodotti {
    id_prodotto (referenza a 
prodotti.id
),
    lang (codice linguaggio ISO),
    l10n_descrizione
}
Manlio Perillo

 carico della CPU.
Dopo esserti arrampicato sugli specchi per mezza giornata ora passi 
direttamente a sparare balle...
1. fin dal primo post ho chiarito (e ribadito *quattro* volte visto che 
tu continuavi, e continui, a vedere solo quello che ti fa comodo) che si 
trattava di una soluzione alternativa, ad uso generale, *non* idonea al 
caso specifico;
2. "ad ogni richiesta HTTP" l'hai aggiunto tu, che o non hai mai visto 
un qualsiasi app server o sei in malafede.

 la traduzione delle descrizioni di un catalogo di 4.500 prodotti.
Vedi sopra.
Buon pranzo,
Paolo

 [/mi quoto]
Non per fare il pignolo ma tony non ha mai parlato di un application
server, cosi' come non lo hai fatto tu fino al post precedente.
[/mi quoto]
Sei sicuro che tony utilizzera' un application server?
Perche' hai indicato che l'alternativa era valida per tradurre "tutto,
non solo articoli o elementi specifici" solo nel caso in cui si
utilizzasse un application server (o tecnologia equivalente)?


 note".
[ti quoto]
Alternativa č creare una tabella di traduzione dove indichi elemento,
suo id, sua traduzione, lingua di traduzione (es.: 'articoli', '123',
'matita', 'it'). Lato applicativo ti fai poi una funzione che carica la
traduzione necessaria nel contesto (es. per tradurre i menů, le
categorie articolo, le note).
Cosě puoi tradurre tutto, non solo articoli o elementi specifici, ma ti
trovi un tabellone cospicuo (seppur solo di quattro colonne).
[/ti quoto]
[mi quoto]
A sentir dire "Alternativa č" e "Cosě puoi tradurre tutto, non solo
articoli o elementi specifici" mi sembra difficile credere che tu non
stessi parlando del caso specifico.
Oltretutto l'esempio che hai portato ("'articoli', '123', 'matita',
'it'") sembra chiaramente riferito alla traduzione di un catalogo di
prodotti.
[/mi quoto]


 database per memorizzare i dati dei prodotti.
E' una delle possibili soluzione. Il principale inconveniente e'
quando, ad esempio, vuoi estrarre 10 record di un catalogo di prodotti
gia' tradotti in una lingua. Ammettendo che vi siano 3 campi (es. nome,
descrizione, optional etc.) l'SQL della query inizierebbe ad essere
molto complesso (un JOIN per ogni campo da tradurre etc.).
La soluzione ottimale e' quella descritta da Paolo:
[quoto 47b1cf31$0$10629$
4faf...@reader2.news.tin.it
]
La tabella dei prodotti deve contenere i prodotti e dati relativi, non
le loro traduzioni.
Quelle le metti in un'apposita tabella contenente solo i campi che
vanno effettivamente tradotti.
In questo modo se devi cambiare il valore di un campo lo cambi solo in
un punto, non in n (dove n = numero di lingue presenti).
[/quoto]
Quando andrai a creare la query vi sara' un solo JOIN tra la tabella
dei prodotti e quella delle traduzioni dei prodotti, migliore in
termini di performance (meno tempo richiesto per il parsing dell'SQL,
della selezione dei record etc.) e di carico del server (query piu'
semplice e facile da ottimizzare internamente). Inoltre avendo piu'
tabelle separate, gli indici rimarranno contenuti invece di "esplodere"
in dimensine, rendendo le ricerche piu' veloci.


 Sei sicuro che tony utilizzera' un application server?
Sono sicuro che tu hai tempo da perdere, io no.
Saluti.

 La soluzione ottimale e' quella descritta da Paolo:
Ahah! :D
Scusa se te lo dico (e senza offesa, eh!) ma, se finora stavi sfiorando 
il ridicolo, ora hai preso il volo... :)
Non vedi che le soluzioni che abbiamo proposto sono identiche, con la 
differenza che Manlio ha aggiunto una descrizione di default (utile se 
si usa soprattutto un linguaggio, per evitare una join)?



No, la join è comunque necessaria, perchè probabilmente avrai bisogno di 
altri dati presenti nella tabella prodotti.
Comunque, per rispondere a Filippo, il join è solo uno, assumendo che i 
dati da tradurre (nome, descrizione, descrizione estesa) si trovano in 
una sola tabella.
Manlio Perillo

 questi dati in un dizionario.  Che c'entra la tabella?
[ti quoto]
Alternativa e creare una tabella di traduzione dove indichi elemento,
suo id, sua traduzione, lingua di traduzione (es.: 'articoli', '123',
'matita', 'it'). Lato applicativo ti fai poi una funzione che carica la
traduzione necessaria nel contesto (es. per tradurre i menu, le
categorie articolo, le note).
Cosi puoi tradurre tutto, non solo articoli o elementi specifici, ma ti
trovi un tabellone cospicuo (seppur solo di quattro colonne).
[/ti quoto]
[mi quoto]
Lo svantaggio di questa soluzione e' che per estrarre anche solo un
record con gli "elementi" gia' tradotti serve una query di una
lunghezza crescente al crescere del numero di campi (con join etc).
[/mi quoto]
[ti quoto]
Vero, ma di solito se si usa "il tabellone" si lavora lato applicativo,
non SQL, usando ad esempio un tag o una funzione specifica nella pagina.
[/ti quoto]
[mi quoto]
Intendi dire che per ogni elemento della pagina che va tradotto (es.
nome prodotto, descrizione, bottone compra etc.) richiami una funzione
che effettua una query sul database ed estrae il valore richiesto?
[/ti quoto]
[ti quoto]
Ni: una funzione effettua un precaricamento (su un dizionario) e
un'altra dal dizionario restituisce la traduzione.
Quindi una sola query.
[/ti quoto]
[mi quoto]
In questo caso il problema sara' la quantita' di memoria richiesta per
caricare il dizionario ed i cicli di CPU necessari per farlo (es.
carica tutte le descrizioni in inglese di 4.500).
[/mi quoto]
[ti quoto]
Prova a fare due conti (anche prendendo descrizioni estese, di 2-3000
caratteri per articolo) e vedrai che l'occupazione di memoria e un
decimo di quella occupata da un qualsiasi web server o anche solo da
applicativi come firefox o simili.
[/quoto]
[mi quoto]
Certo, per un singolo client. Poi, moltiplicalo per 10, 100, 1.000
client concorrenti. A questo aggiungici il tempo impiegato ad ogni
richiesta HTTP per caricare i dati in memoria i dati.
[/mi quoto]
[ti quoto]
Le decodifiche, traduzioni, properties, etc. sono tipicamente elementi
che vanno caricati a livello di application server, non certo di
sessione.
[/ti quoto]
9 post dopo ed inizi a parlare di application server.
Resto ancora in attesa di sapere perche' non hai indicato che
l'alternativa era valida per tradurre "tutto, non solo articoli o
elementi specifici" solo nel caso in cui si utilizzasse un application
server (o tecnologia equivalente).


 trovano in una sola tabella.
Si, me ne sono accorto dopo aver inviato il messaggio. 
Leggendo l10n_prodotti pensavo fosse la tipica tabella utilizzata nelle
strutture l10n per la traduzione multipla ( lang | msgid | msgstr ).
Rileggendo il tuo messaggio mi sono accorto che si trattava della
stessa soluzione solo che ormai il post era partito.


 server (o tecnologia equivalente).
Premesso che non ho detto che è valida *solo se*, ma che è "tipicamente 
usata" (almeno leggi quello che quoti, dai...) e già questo 
risponderebbe alla tua domanda, rispondo:
perché i casi in cui non si lavora con un application server sono 
rarissimi (devo quotare il post in cui lo affermavo?)?
Perché dipende dalle necessità dell'applicazione: se ho bisogno di dare 
risposte molto rapide agli utenti, fossero anche decine di migliaia, me 
ne frego di spendere 1000 euro in RAM e i dati li tengo in memoria 
(veloce), non in hard disk (lento)?
Perché a domanda generica ho dato risposta generica, finché tu non hai 
chiesto dettagli specifici (che con la domanda originaria c'entravano 
come i cavoli a merenda, ma questo è un dettaglio trascurabile)?
Perché ci sono decine di algoritmi e pattern (pure qui vuoi che ti quoti 
il post?) per gestire oggetti in memoria condivisa con n-mila linguaggi 
(e per quella soluzione non serve altro)?
Se mi vengono in mente altre motivazioni te le invio.

 Resto ancora in attesa [...]
Visto che mi ci fai pensare: e le varie domandine che ti ho fatto tra un 
post e l'altro e a cui non hai risposto (praticamente tutte... anzi: tutte)?

 linguaggi (e per quella soluzione non serve altro)?
[mi quoto]
In PHP, il linguaggi di sviluppo per il web piu' diffuso al mondo
(oltre 20 milioni di domini), senza usare la memoria condivisa (non
sempre disponibile), senza dover rielaborare i dati ad ogni richiesta
(es. caricarli dal database), senza utilizzare le sessioni (che
comporterebbero comunque un uso spropositato di memoria), come
caricheresti in memoria oggetti condivisi?
[/mi quoto]


 anzi: tutte)?
Non tutte.
[ti quoto]
A fare cosa? Documentare, prego.
[/ti quoto]
Risposto in 
xn0fme0n...@creativepark.it
[ti quoto]
Inutile ribadire per la terza volta che non era la soluzione al
problema (quella era la prima parte della risposta), ma
un'*alternativa* utile in casi particolari, giusto?
[/ti quoto]
Domanda retorica.
[ti quoto]
Non vedi che le soluzioni che abbiamo proposto sono identiche, con la
differenza che Manlio ha aggiunto una descrizione di default (utile se
si usa soprattutto un linguaggio, per evitare una join)?
[/ti quoto]
Risposto in 
xn0fme1r...@creativepark.it
[ti quoto] 
Non puoi forse usarla (il primo campo diventa opzionale) per fare
quello che ho (e che hai, visto che la tua risposta era molto simile)
suggerito nella prima e principale risposta?
[/ti quoto]
Domanda retorica.
[ti quoto]
Tu lavori via http con questa mole di utenti senza avere alle spalle un
application server?
[/ti quoto]
Risposto in 
xn0fmdzp...@creativepark.it
Se ci sono domande a cui non ho dato risposta e che ritieni opportuno
che risponda, e' sufficiente che le elenchi.


 [/mi quoto]
Devo quotare la risposta che ti ho già dato?

 Domanda retorica.
Ovvio che sono domande retoriche: mai sentito parlare di sarcasmo?
E a certe ti sei pure messo a rispondere...

 E a certe ti sei pure messo a rispondere...
P.S.: visto che il gradino dopo il sarcasmo è l'offesa (che non è 
decisamente nelle mie abitudini) e che, come già detto, non ho tempo da 
sprecare in flame (ripeto: leggiti la definizione di application server 
e trovami un esempio di un'applicazione web che non ne faccia uso), 
preferisco chiudere definitivamente qui.
Ti saluto,
Paolo

 Devo quotare la risposta che ti ho già dato?
Lo prendo com un no.


 definitivamente qui.
Non ho trovato da nessuna parte scritto che il PHP e' un application
server, potresti indicarmi dove, sul sito 
www.php.net
, lo scrivono?
Se lo fosse, l'installazione di default non dovrebbe fornire un
meccanismo diretto (come l'oggetto Application di 
ASP.NET
) per salvare
un dizionario con le traduzioni in memoria all'avvio del server?


 server, potresti indicarmi dove, sul sito 
www.php.net
, lo scrivono?
Il sito 
php.net
 è dedicato al linguaggio.
Forse dimentichi (o forse ti fa comodo fingere di dimenticarlo per 
polemizzare) che per far girare su web il PHP si usa mod_php (o simili): 
un modulo di un web server che fornisce proprio quelle funzionalità 
aggiuntive (mi rifiuto di ripeterle, sono comunque ben indicate nel link 
a wikipedia che hai indicato) che identificano un application server.
Non commento il fatto che la pagina di wikipedia che indichi non citi 
php: non cita neanche app server in python (escluso Zope), ruby, C++.
Leggiti il paragrafo "Common features" (o, se preferisci, "Struttura 
modulare" nella versione in italiano) e dimmi se PHP non fa praticamente 
tutte le cose ivi indicate.
Tutto il resto è noia... (cit.) ;)
Un paio di riferimenti ulteriori (trovati in circa 20 secondi, nelle 
prime due pagine di risultati):
adobe: 
livedocs.adobe.com/dreamweaver/8/using/25_web10.htm
O'Reilly: 
safari.oreilly.com/0672324032/ch07lev1sec4
(ci sono poi altri 3-4 risultati ma di aziende meno note o di siti di 
documentazione/esempi, puoi cercare inoltre sotto 
bugs.php.net
 o sui ng 
di PHP per trovare altre centinaia di occorrenze)
Ciao,
Paolo

 altre centinaia di occorrenze)
Giusto per fare il punto.
La soluzione alternativa proposta
(47b1cf31$0$10629$
4faf...@reader2.news.tin.it
) necessita di un
application server per essere utilizzata
(47b28ca6$0$17945$
4faf...@reader1.news.tin.it
). Secondo la tua
opinione PHP e' un application server
(47b32616$0$4792$
4faf...@reader4.news.tin.it
) per cui la soluzione
alternativa puo' essere utilizzata in PHP.
La mia domanda, e' come?
Come su puo' caricare un dictionary all'avvio dell'"application server"
PHP ed averlo accessibile in tutte le sessioni come si fa con altri
"application server" senza doverlo ricaricare ad ogni richiesta?
Se PHP e' un "application server", non dovrebbe fornire tale
funzionalita' nativamente come fanno tutti gli altri "application
server"?


 systems, etc).
Prima risposta di google a middleware:
http://it.wikipedia.org/wiki/Middleware
Ma almeno sai cosa significa LAMP? Non è, per caso, incluso un web 
server? E un db? E un linguaggio di integrazione tra i due, con in più 
gestione di transazioni, connessioni, sessioni, memoria condivisa (tutte 
cose citate in questa pagina e in quella precedentemente segnalata da te)?
Stai scadendo nel ridicolo... e, scusa, io mi son annoiato.
Se vuoi continuare a pensare che application server significhi solo J2EE 
o .Net, liberissimo di farlo.
Buon proseguimento,
Paolo

 J2EE o .Net, liberissimo di farlo.
Prendiamo Cerise, un application server in Ruby. In cosa consiste? In
un socket server che risponde alle richieste dei client tramite un
server HTTP interno (che non e' l'application server), fornisce un
ambiente nel quale le risorse vengono condivise e le richieste vengono
processate dalle applicazioni ospitate.
[mi quoto]
Tutti gli application server elencati su Wikipedia includono un server
a se stante. LAMP no, come te lo spieghi?
[/mi quoto]


 J2EE o .Net, liberissimo di farlo.
A me però il php in sé non sembra un application server.
Sbaglierò, eh...
-- 
ValeRyo - GS500F "Camilla"
Comitato Per La Salvaguardia Dell'Italiano
E anche tu potrai dire: quest'hanno c'è l'ho l'iscrizione!
Se impareremmo i congiuntivi fossimo persone migliori! 

 Sbaglierò, eh...
Non so se hai letto i post precedenti (spero per te di no ;) ), in ogni 
caso quello che sottolineavo è che "application server" (come "framework 
web", "AJAX", "enterprise") è una di quelle definizioni talmente 
generiche da indicare tutto e niente.
Facevo notare al Toso che, prendendo la definizione *generale* (quindi 
trascurando definizioni di specifici e standardizzati app server) del 
termine (tra l'altro la stessa da lui citata da wikipedia), le 
funzionalità che vengono indicate per identificare un app server sono 
anche tutte presenti (o implementabili con poche righe di codice) usando 
apache + mod_php (quindi non solo PHP, che è un linguaggio).
Tra l'altro alcune di queste funzionalità (es. interfaccia a sistema 
legacy, altro /parolone multiuso/) non sono presenti neanche in 
application server "riconosciuti".
Si parlava in particolare (e in generale) di protocollo HTTP, componenti 
server-side, gestione degli accessi degli utenti e della sicurezza, 
gestione accesso a database, gestione transazioni.
Tutte cose che si trovano nativamente e di default in apache + mod_php.
Questo anche per sottolineare che un application server non è 
l'universo, ma una semplice applicazione che altro non fa che tenere in 
piedi altre applicazioni http, fornendo loro le funzionalità appena 
citate in modo condiviso e gestibile a livello globale, di applicazione 
e di utente (sessione).
Che poi apache + PHP/mod_php, visto come app server, abbia funzionalità 
molto più limitate e limitanti di altri è scontato dirlo anche se è pur 
vero che ci sono app server che di funzionalità ne hanno anche meno e 
nessuno si sogna di dire che non siano app server.
Vedi ad esempio Cherrypy in Python, per citare il primo caso che mi 
viene in mente.
Tutto qui.
Poi da una mosca (polemica) è nato l'elefante...
Ciao,
Paolo

 hanno anche meno e nessuno si sogna di dire che non siano app server.
E su questo punto che non mi trovi d'accordo.
Per me un application server è un qualcosa che installo e mi fornisce
un tot di funzionalità (vedi .net) consentendomi di scrivere
appserver.db.connect(); // tutte le specifiche sono in app.config
appserver.template.load('show_utenti.htm');
appserver.template.data.utenti = appserver.db.select('utenti', 'mailbox_no = 
2', 'data_iscrizione ASC');
appserver.template.show();
Anche se questo lo fa pure un framework, ma al momento non mi
viene un esempio migliore :-)
Con il php+apache posso fare questo? Non mi pare.
Certo, scrivendoci un po' di codice intorno si, ma allora sto
scrivendo un application server :-)
Altrimenti seguendo il tuo ragionamento si è costretti ad affermare
che anche IIS+C fanno un application server.
Sulle funzionalità limitate non ci vedo problemi, se ho un application
server orientato alla gestione di database non mi stupirò se non ha
funzioni specifiche per la grafica e viceversa.


 che anche IIS+C fanno un application server.
Si è costretti ad affermarlo non seguendo il mio ragionamento ma se 
IIS+C forniscono (sempre parlando in termini generici) le funzionalità 
elencate nel post precedente.
Sessioni? No; connessione a db? neanche; gestione transazioni? nemmeno...
Ciao,
Paolo

 nemmeno...
Uh bella, e perché no?
Mica il php conosce i db di suo... si linka la libreria. Allo stesso modo
si fa con il C. Idem per transazioni, grafica (le gd sono pure le stesse
del php) e qualunque altra cosa di cui dovessi avere bisogno e per
cui è stata scritta una libreria.


 si fa con il C.
Perché nel linguaggio php sono comprese delle funzioni per la 
connessione a mysql, in C standard no.
Poi è vero che gran parte dei db sono scritti in C/C++ quindi da C è 
facile interfacciarsi. Ma devi farlo tu, non trovi le funzioni incluse.
E resta da fare tutto il resto che contraddistingue (sempre in termini 
molto generici) un app server: sessioni, memoria condivisa, transazioni...
Ciao,
Paolo

 connessione a mysql,
Sono comprese le librerie mysql per ragioni storiche, prima era
comunque necessario linkare la libreria mysql, come ancora oggi
è necessario linkarne tante.
Comunque resto della mia idea, il php è un linguaggio e non un
application server :-)


 application server :-)
Ma su questo ti do ragione! :)
Avevo chiarito che php è un linguaggio, apache + mod_php si può 
considerare un app server.
Ciao,
Paolo

Paolo
ragazzi,
non volevo scatenare questo putiferio.
fatico a seguirvi, purtroppo.
confermo che uso mysql e php, ma non certo ai vostri livelli.
mi limito a creare qualche join e qualche query piu' o meno semplice.
lo so che dovrei studiare ancora parecchio, ma purtroppo, nell'ambito
del progetto che devo seguire non ho la possibilità di farlo bene.
io mi sarei "limitato" (e' gia' tutto dire...) a duplicare i vari
record in base alla lingua. Ogni recordo con un ID_lingua.
Ma mi avete convinto ad intraprendere un'altra strada: creare una
tabella con le informazioni traducibili.
Domanda:
mi conviene creare una tabella per ogni campo da tradurre?
oppure creo una unica tabella con tutti i campi da tradurre?
ho paura che la seconda ipotesi mi tagli le gambe se devo cambiare un
po' la struttura del db.
Nel primo caso, mettiamo che creo una tabella per la traduzione del
campo 'descrizione'.
Come la strutturo?
Tabella traduzione descrizione:
| id_trad | IT | UK | DE | ES |
Poi, nel caso si debba aggiungere una lingua, non devo fare altro che
aggiungere una colonna (es.: RU).
Puo' andare?
Posso comprendere che possano esserci (anzi, che ci sono SICURAMENTE)
soluzioni migliori, ma tutto va rapportato alle mie capacita', in
questo momento.  :(.
In generale, usando questa soluzione avrei i miei 4.500 record nella
tabella articoli e poi n tabelle delle traduzioni.
In qualcuna di queste tabelle di traduzione potrei trovarmi anche
4.500 records, come nel caso delle descrizioni,dove ogni prodotto
potrebbe avere una descrizione diversa.
Idem qualche altra tabella di traduzione.
E qui mi sorgono altri dubbi. Che vantaggi posso avere rispetto alla
duplicazione dei record della tabella articoli per N lingue? visto che
poi mi ritrovo con tante tabelle che possono avere lo stesso numero
(se non di piu') di record della tabella articoli? E' una
estremizzazione, ma puo' capitare.
E se puo' capitare, capitera', come diceva qualcuno. ;).
Ciao e scusate la mia ignoranza.
tony
p.s.: c'e' da imparare parecchio nel leggervi. Grazie.

 estremizzazione, ma puo' capitare.
Nessun vantaggio, perché stai usando una soluzione che è un problema ;)
Per ricapitolare il tutto ti propongo una struttura (semplificata) 
tabelle con dei dati d'esempio:
Articoli
IDArticolo, [campi che non necessitano di traduzione]
[es.]  001,  [prezzo, codice categoria...]
(chiave primaria unique: IDArticolo)
Articoli_Traduzioni
IDArticolo, lingua, nome, descrizione, note
[es.]  001, 'it', 'pinza', 'pinza per estrazione molari', 'placcata in 
titanio'
(chiave primaria unique: IDArticolo, lingua)
La query da usare:
select * from articoli art
join articoli_traduzioni trad
on art.IDArticolo = trad.IDArticolo
where lingua = 'it'
Ciao,
Paolo
P.S.: perché non posti la questione su i.c.s.database? Mi sembra più in 
tema...

>P.S.: perché non posti la questione su i.c.s.database? Mi sembra piů in 
lo scopro adesso! 8O.
ok.
ciao
tony