Struttura di un sito multilingua e condivisione database degli utenti.

Sto sviluppando un portale abbastanza grande e ho l'esigenza di dover condividere gli utenti ed altri dati in tutte le aree del portale (che saranno "autonome" sui contenuti, a loro volta anche in base alla lingua).

Come potrei strutturare i DB? Ho anche qualche dubbio sul DB Parser, ma che credo che usando un valore alla funzione di connessione, poi riesca tranquillamente a risolvere il problema. Eventualmente consigliate un metodo che avete visto o che usereste.

Vi ringrazio in anticipo

Nulla di tanto esotico o complesso.

Mettiamo che hai un ipotetica tabella news/articoli (o quel che sia) che ti mostra delle anteprime in una zona della homepage e nella giusta lingua a seconda di quella selezionata dall'utente.

Basta avere in questa tabella una banalissima colonna, magari dichiarata come char(2) e indicizzata, in cui appunti per ogni contenuto l'identificativo della lingua in cui è scritto ( en, it o quello che ti pare :p ).

A questo punto è facile creare una clausola dinamica nella query di recupero di quelle informazioni a seconda della lingua scelta.

Ci ho pensato, ma ho bocciato l'idea per il semplice fatto che è un portale e tutte le aree sono multilingua, non voglio gravare su tutti i contenuti sullo stesso DB, dato che essendo internazionale, troppe richieste sincrone rischierebbe di rallentare od addirittura buttare giù il server MySQL.

Quindi vorrei suddividere i DB in base alla lingua, al loro interno usare la STESSA struttura (tabelle, ecc) e richiamarli dallo script in base alla lingua, quindi la connessione varia in base alla lingua.

La tua struttura potrebbe tornare utile per un portale multilingua che ha solo news o comunque contenuti simili, ma per un portale dove ci sarà TUTTO (forum, news, applicazioni e features), sarebbe troppo controproducente secondo me.

In ogni caso grazie per la risposta.

Ci ho pensato, ma ho bocciato l'idea per il semplice fatto che è un portale e tutte le aree sono multilingua, non voglio gravare su tutti i contenuti sullo stesso DB, dato che essendo internazionale, troppe richieste sincrone rischierebbe di rallentare od addirittura buttare giù il server MySQL.
La tua struttura potrebbe tornare utile per un portale multilingua che ha solo news o comunque contenuti simili, ma per un portale dove ci sarà TUTTO (forum, news, applicazioni e features), sarebbe troppo controproducente secondo me.

In ogni caso grazie per la risposta.

Secondo me stai accorpando insieme più cose del dovuto.
Per la traduzione della struttura del sito e delle sue funzionalità puoi usare un pratico sistema di files di lingua da includere a seconda della lingua scelta dall'utente.

Ciò che ti entra nel db dovrebbero essere solo contenuti dinamici, come i commenti degli utenti o gli articoli di un blog.

A questo punto temi un alto traffico di utenti ? Considera innanzitutto che MySql non va sottovalutato in proposito, finchè mantieni sensate le logiche relazionali e definiti i giusti indici alle tabelle potrebbe sorprenderti per i carichi che è capace di sostenere ( chiaramente, dipende anche dalla macchina server su cui poggia ) sia come archiviazione ( chiaramente nelle MyIsam ) che come prestazioni delle query SQL.

Ha i suoi limiti certo, ma il punto è che se prevedi di raggiungerli allora neanche scindere i DB servirebbe a molto in quanto non è la mole di dati ad essere il problema ma la frequenza con cui le risorse vengono richieste, l'unica cosa di cui hai bisogno è un sistema di caching server side dei contenuti pseudo-statici del tuo portale ( esempio, un articolo di blog ) così da evitare l'utilizzo di risorse inutili per produrre ad ogni richiesta il medesimo output.

Sono uno fissatissimo per le ottimizzazioni sotto ogni fronte. Ho già quel che tu dici e non è quello il mio problema. Ho un sistema Cache e Multilingua che, con presunzione probabilmente, posso dire sia perfetto.

Ora come ora sono costretto a rimanere su una macchina condivisa e quindi devo temere il traffico e le richieste al DB, ottimizzate o meno che siano. Certo, più sono ottimizzate più ne posso avere, ma essendo appunto un server condiviso, anche il MySQL rischia di andare giù per il troppo traffico.

Il tuo sistema lo utilizzo nel mio sito personale perché i contenuti sono davvero pochi rispetto a quel che sto sviluppando, ma se dovessi fare una cosa, per esempio, come Last.fm, la boccio anche perché dividerò i DB sia per le questioni appena scritte, sia perché farò li farò hostare nel paese più vicina alla lingua.

Io vorrei avere, in poche parole, un DB UNICO dove ci saranno gli utenti e tutto ciò che riguarda loro (permessi e dati), poi le sezioni/categorie del Forum suddivise come tu hai detto (cioè con un campo con l'ISO della lingua) e tutto ciò che rimane GLOBALE a livello "internazionale", poi un DB per OGNI LINGUA in modo da salvare al loro interno tutti i dati di quella lingua.

Il mio problema sorge nello sviluppare un DB parser che possa comunicare, senza appesantire il CMS, con tutti i DB. Siccome utilizzo le sessioni lato MySQL e non tramite PHP, dovrei tenere sempre aperte ALMENO 2 connessioni per pagina: una per i dati dell'utente ed una per i dati delle pagine.

Infatti chiedevo altre soluzioni (oltre quella del campo con l'ISO della lingua e l'estrazione apposita) per evitare di avere tutto il contrario che un sito ottimizzato.

[..] la boccio anche perché dividerò i DB sia per le questioni appena scritte, sia perché farò li farò hostare nel paese più vicina alla lingua.

Io vorrei avere, in poche parole, un DB UNICO dove ci saranno gli utenti e tutto ciò che riguarda loro (permessi e dati),
[..]
poi un DB per OGNI LINGUA in modo da salvare al loro interno tutti i dati di quella lingua.

Il mio problema sorge nello sviluppare un DB parser che possa comunicare, senza appesantire il CMS, con tutti i DB. Siccome utilizzo le sessioni lato MySQL e non tramite PHP, dovrei tenere sempre aperte ALMENO 2 connessioni per pagina: una per i dati dell'utente ed una per i dati delle pagine.

Per carità, lungi da me nel criticare sistemi che non conosco: mai messo in dubbio che il tuo sistema di cache fosse poco efficiente, semplicemente erano oscuri un po di punti ;-)


Infatti ora mi è più chiaro quello che vuoi realizzare.
Già di per se, settorializzare i database destinati alle varie lingue è una buona cosa ed aiuta non poco in un applicazione ad alto traffico di utenza.

Quanto alle connessioni ai db, o ricorri alle sessioni in PHP o trasli la tabella di gestione delle sessioni account nei DB di lingua.


> Sessioni in PHP
L'idea è che quando un utente esegue l'accesso al sito le configurazioni base del DB principale vengano archiviate in sessione così da permetterti l'utilizzo di una sola connessione per volta ad ogni esecuzione dello script.

Successivamente puoi controllare periodicamente le informazioni dell'utente: puoi far si che la sessione abbia una durata di scadenza veramente ridotta, tra i 5 e gli 8 minuti, a seguito dei quali il tuo engine potrebbe far partire una nuova richiesta al main DB, al fine di aggiornare permessi e informazioni critiche relative all'account in uso.


> Sessioni in DBs di lingua
Il concetto è come per le sessioni in php, prelevi le informazioni relative all'account nel main DB all'atto del login e le archivi in una tabella del lang DB che usi per gestire la sessione dell'account.

Quando un utente vuol passare dalla lingua inglese a quella italiana puoi chiamare una procedura che successivamente trasla, se presente, il riferimento di sessione nel db di lingua inglese. In questo modo eviti che cambiando lingua si perda la sessione per strada.


> In entrambi

In sostanza il consiglio è: sfrutta la connessione al db primario e/o tra quelli secondari solo quando ne hai realmente bisogno.


Quanto al DB parser per comunicare in contemporanea con tutti i db non so, sicuro non si sfugge dal fatto che bisogna fare un autenticazione per ogni db su cui vuoi operare, visto che intendi metterli su diversi server, ma ritengo che una prospettiva simile debba capitare in funzione di un qualche strumento di gestione globale del sito e accessibile quindi solo all'amministratore globale della baracca.

No no, aspetta! Mi hai sicuramente frainteso Ho semplicemente detto che per quello non problemi perché per le mie esigenze, il sistema è perfetto

Il sistema delle sessioni sono obbligato ad averlo su unico server, perché devo visualizzare le persone online in GENERALE, poi eventualmente filtrerò, ma su quelle generale è inconcepibile aprire tante connessioni quante le linge per contare chi è online.

Sul fattore della perdita della lingua selezionata, non ci sarà problema perché ho sviluppato il sistema in modo che se cambi lingua da Ospite, al momento del login, mantieni la lingua selezionato in precedenza e viceversa, se esegui il Logout, mantieni la lingua della sessione precedente anche da Ospite.

Per il parser mi sa passerò il nome alla funzione che si connette facendo un ciclo per tutti i DB a cui collegarmi, poi utilizzerò la sintassi delle query anteponendo il DB al nome della tabella in modo da estrarre i dati da dove mi serve. Mi pare l'unica soluzione plausibile al momento.

In ogni caso ti ringrazio infinitamente delle idee e del supporto, 2 teste sono meglio di una.

Allora si, ti tocca tenere attive due connessioni.
Però puoi migliorare di molto le prestazioni della tabella delle sessioni nel main DB se la definisci di tipo memory ( in sostanza, alloca i dati direttamente sulla RAM del server ).

Comunque di nulla, lieto se sono riuscito a darti qualche idea e un in bocca al lupo per il progetto ;-)

sicuramente soino meno esperto di voi.. ma mi domandavo una stuttura come magento puo andar bene ?

La butto li... un database con poche tabelle per i dati non internazionalizzabili, e le tabelle internazionalizzate con il name preceduto da un prefisso diverso in funzione della lingua da utilizzare.

A quel punto se sai la lingua da utilizzare basta che nelle query fai una cosa tipo:

$query = "SELECT * FROM ".$prefisso_lingua."nome_tabella";

ed esegui la query.

Ciao