[PHP+MySQL]Database, lingue e capocciate

[Lwyrn]

Sto mettendo insieme un piccolo sistema che ( in teoria ) dovrebbe gestire migliaia di prodotti e di pagine di testo che però possono essere localizzate in un numero indefinito di lingue ( dinamicamente a scelta dell'amministratore ).
Sono un bel pò dubbioso sul tipo di sistema da utilizzare perché ognuna delle soluzioni che mi vengono in mente hanno tanti contro quanti pro. Prendete in considerazione che le "estensioni" che si occupano delle gestione dei vari compenti ( es prodotti, news etc. ) devono gestire automaticamente l'implementazione del numero indefinito di lingue. Quindi non posso preventivare campi specifici che andranno a gestire le rispettive lingue.
Di base ho pensato che viene definita una lingua principale dall'amministratore o dal sistema stesso. E questo mi pare anche abbastanza scontato
In anticipo ho pensato di creare un apposita colonna dedicata ( per ogni tabella che ne abbia la necessità ) per contenere array multidimensionali serializzati che contengono tutte le parti localizzate necessarie ( ad esempio titolo, descrizione o cos'altro ).
Potrebbe rivelarsi una situazione comoda per quanto riguarda la gestione da php che diventa molto più scorrevole e la pulizia nel database.
Diventa assolutamente scomodo però quando si comincia a voler fare query personalizzate per estrarre dati in determinati lingue. Ergo, diventa abbastanza difficile da gestire se si vogliono fare campi personalizzati di ricerca nel sito per lingue diverse da quella standard. Si dovrebbe cominciare a lavorare con query che sfruttano espressioni regolari per farsi strada tra la lunga stringa che verebbe fuori da un array serializzato, con conseguenti rallentamento delle query che, sopratutto su migliaia di articoli, comincerebbe a rallentarsi un bel pò. Per non considerare la limitazione che si avrebbe nel non poter usare istruzioni piu complesse.
Altra soluzione a cui ho pensato è quella di far creare ( si parla sempre in modo dinamico ) dal sistema n. tabelle per quante sono le lingue con un prefisso contenente il distintivo della lingua ( es products_it, product_es, products_en etc ). I pro sono ovviamente di poter fare delle semplicissime query cambiando solo il prefisso della tabella in caso si vogliano ricercare dati o effettuare query più complesse. Aumenterebbero però la difficoltà nella gestione del tutto. Si ci dovrebbe assicurare di far combaciare gli id della lingua principale con quelli delle tabelle secondarie, assicurarsi di cancellare le righe simultaneamente e aggiungere dei flag-field per determinare se un determinato prodotto è presente o meno in quella determinata lingua. Per non parlare dell'enormità di tabelle che ne uscirebbero fuori e sopratutto delle dimensioni: si arriverebbe a duplicare, triplicare, quadruplicare e così via la dimensione del database in base al numero di lingue utilizzate.
Altri metodi al momento non me ne sono venuti, però vorrei fare in modo di poter gestire il tutto cercando di aver un buon rapporto prestazioni/facilità di gestione, e sono parecchio indeciso.
Voi che dite, avete qualche idea da consigliarmi ? Qualsiasi idea è ben accetta!

[VICIUS]

Che ne dici di questo?

Una tabella prodotto che contiene tutto quello che non serve tradurre. Una per la lista delle lingue. E poi metti tutti i dati tradotti in una terza tabella che ha come chiave primaria l'id del prodotto e della lingua.

[Lwyrn]

Originariamente inviato da VICIUS

Che ne dici di questo?

Una tabella prodotto che contiene tutto quello che non serve tradurre. Una per la lista delle lingue. E poi metti tutti i dati tradotti in una terza tabella che ha come chiave primaria l'id del prodotto e della lingua.

Ummm, sicuramente molto meglio che duplicare intere tabelle! E si potrebbe collegare il tutto con delle join, sicuramente molto meno disordinato che creare trecentomila tabelle. Hai usato MysqlWorkbench per lo schema ?

[VICIUS]

Esatto.