MySQL Datenbank Design mit Internationalisierung

Question

Ich werde mit der Arbeit an einer mittelgroßen Anwendung beginnen, und ich plane es ist db-Design. Eine Sache, über die ich mir nicht sicher bin, ist diese. werde ich viele Tabellen haben, die Internationalisierung benötigen, wie zum Beispiel: "membership_options, gender_options, language_options etc"

Jede dieser Tabellen werden gemeinsame i18n Felder teilen, wie: "title, alternative_title, short_description, Beschreibung"

Was ist Ihrer Meinung nach der beste Weg? Haben Sie eine i18n Tabelle mit den gleichen Feldern für jede der Tabellen, die sie brauchen?

oder so etwas wie:

Membership table  Gender table 
----------------  -------------- 
id | created_at  id | created_at 
1 - 22.03.2001  1 - 14.08.2002 
2 - 22.03.2001  2 - 14.08.2002 


General translation table 
------------------------- 
record_id | table_name | string_name | alternative_title| .... |id_language 
1  - membership regular   null      1 (english) 
1  - membership normale   null      2 (italian) 
1  - gender  man    null      1(english) 
1  -gender  uomo   null      2(italian) 

Dies würde vermeiden mich wie etwas zu wiederholen:

membership_translation table 
----------------------------- 
membership_id | name | alternative_title | id_lang 
1    regular null    1 
1    normale null    2 

gender_translation table 
----------------------------- 
gender_id | name | alternative_title | id_lang 
1   man  null    1 
1   uomo null    2 

und so weiter, so würde ich wahrscheinlich die Anzahl der DB-Tabellen reduzieren, aber ich bin bin mir nicht sicher über die Leistung. Ich bin nicht viel von einem DB-Designer, also lass es mich wissen.

Answer 1

Die gängigste Methode, die ich gesehen habe, ist mit zwei Tabellen, membership und membership_ml, wobei eine die Basiswerte und die ml-Tabelle die lokalisierten Zeichenfolgen speichert. Dies ist ähnlich wie bei Ihrer zweiten Option. Die meisten Systeme, die ich so sehe, wurden so erstellt, weil sie nicht von Anfang an auf Internationalisierung ausgelegt waren, daher wurden die zusätzlichen _ml-Tabellen später "angeheftet".

Was ich denke, ist eine bessere Option ist ähnlich wie Ihre erste Option, aber ein bisschen anders. Sie würden eine zentrale Tabelle zum Speichern aller Übersetzungen haben, aber anstatt den Tabellennamen und den Feldnamen einzugeben, würden Sie Tokens und eine zentrale Tabelle "Inhalt" verwenden, um alle Übersetzungen zu speichern. Auf diese Weise können Sie eine Art von RI zwischen den Token in der Basistabelle und den Übersetzungen in der Inhaltstabelle erzwingen, wenn Sie das möchten.

Ich eigentlich asked a question über diese Sache eine Weile zurück, so können Sie sich das für einige weitere Informationen ansehen (anstatt die Schema-Beispiele hier zu überarbeiten).

Answer 2

Ich denke auch, die beste Lösung ist es, Übersetzungen auf verschiedenen Tabellen zu halten. Dieser Ansatz verwendet Open Cart, der Open Source ist und Sie können einen Blick darauf werfen, wie es mit dem Problem umgeht. Eine weitere Informationsquelle ist hier "http://www.gsdesign.ro/blog/multilanguage-database-design-approach/" speziell zu den Kommentaren