Design einer DB für mehrsprachigkeit - Seite 4

Squall · 21.08.2010, 01:23

Ok, hier mal ein Beispiel einer möglichen Struktur.

Diese Tabelle soll, den Namen eines Landes (in beliebig vielen Sprachen) und dessen gesamtfläche speichern.

Code:

laender
+------+---------+
| trid | flaeche |
+------+---------+
| 1    | 400qm   |
+------+---------+
| 2    | 200qm   |
+------+---------+

Diese Tabelle soll, den Namen einer Stadt (in beliebig vielen Sprachen) und dessen Einwohnerzahl speichern.

Code:

staedte
+------+-----------+
| trid | einwohner |
+------+-----------+
| 1    | 1000      |
+------+-----------+
| 2    | 4000      |
+------+-----------+

In dieser Tabelle stehen alle namen der DB-Tabellen in dennen sprachvariablen vorkommen können.

Code:

tables
+-----+---------+
| tid | name    |
+-----+---------+
| 1   | laender |
+-----+---------+
| 2   | staedte |
+-----+---------+

In dieser Tabelle stehen die Namen der DB-Felder die normalerweise in den Tabellen Laender bzw. staedte stehen würden

Code:

fields
+-----+------+
| fid | name |
+-----+------+
| 1   | name |
+-----+------+

In dieser Tabelle stehen die sprachen die zur verfügung stehen sollen.

Code:

langs
+-----+------+
| lid | name |
+-----+------+
| 1   | de   |
+-----+------+
| 2   | en   |
+-----+------+

Diese Tabelle verbindet dann alles miteinander und kann auch anhand der gespeicherten daten, den eintrag in dem die übersetzung verwendet werden soll zurückverfolgen.

Code:

tables_fields_langs_texts
+-----+-----+-----+-----+------+-------------+
| id  | tid | fid | lid | trid | txt         |
+-----+-----+-----+-----+------+-------------+
| 1   | 1   | 1   | 1   | 1    | Deutschland | # Tabelle "laender" feld "name" sprache "de" id "1"
+-----+-----+-----+-----+------+-------------+
| 2   | 1   | 1   | 2   | 1    | Germany     | # Tabelle "laender" feld "name" sprache "en" id "1"
+-----+-----+-----+-----+------+-------------+
| 1   | 1   | 1   | 1   | 2    | Frankreich  | # Tabelle "laender" feld "name" sprache "de" id "2"
+-----+-----+-----+-----+------+-------------+
| 2   | 1   | 1   | 2   | 2    | France      | # Tabelle "laender" feld "name" sprache "en" id "2"
+-----+-----+-----+-----+------+-------------+
| 5   | 2   | 1   | 1   | 1    | München     | # Tabelle "staedte" feld "name" sprache "de" id "1"
+-----+-----+-----+-----+------+-------------+
| 6   | 2   | 1   | 2   | 1    | Munich      | # Tabelle "staedte" feld "name" sprache "en" id "1"
+-----+-----+-----+-----+------+-------------+
| 7   | 2   | 1   | 1   | 1    | Rom         | # Tabelle "staedte" feld "name" sprache "de" id "2"
+-----+-----+-----+-----+------+-------------+
| 8   | 2   | 1   | 2   | 1    | Rome        | # Tabelle "staedte" feld "name" sprache "en" id "2"
+-----+-----+-----+-----+------+-------------+

Mit beliebig erweiterbar meine ich dass im nachhinein z.b. noch die Tabelle sehenswürdigkeiten dazu kommen kann.

Code:

sehenswuerdigkeiten
+------+------------------+
| trid | oeffnungszeiten  |
+------+------------------+
| 1    | 9:00 - 14:00     |
+------+------------------+
| 2    | 8:00 - 20:00     |
+------+------------------+

Somit muss ich nur noch die tabelle "tables" erweitern

Code:

tables
+-----+---------------------+
| tid | name                |
+-----+---------------------+
| 3   | sehenswuerdigkeiten |
+-----+---------------------+

Und kann dann in der "tables_fields_langs_texts" meine übersetzungen einbauen und problemlos zurückverfolgen

Code:

tables_fields_langs_texts
+-----+-----+-----+-----+------+-------------------+
| id  | tid | fid | lid | trid | txt               |
+-----+-----+-----+-----+------+-------------------+
| 9   | 3   | 1   | 1   | 1    | Eifelturm         | # Tabelle "sehenswuerdigkeiten" feld "name" sprache "de" id "1"
+-----+-----+-----+-----+------+-------------------+
| 10  | 3   | 1   | 2   | 1    | eifel tower       | # Tabelle "sehenswuerdigkeiten" feld "name" sprache "en" id "1"
+-----+-----+-----+-----+------+-------------------+
| 11  | 3   | 1   | 1   | 2    | freiheitsstatue   | # Tabelle "sehenswuerdigkeiten" feld "name" sprache "de" id "2"
+-----+-----+-----+-----+------+-------------------+
| 12  | 3   | 1   | 2   | 2    | statue of liberty | # Tabelle "sehenswuerdigkeiten" feld "name" sprache "en" id "2"
+-----+-----+-----+-----+------+-------------------+

Hoffe das jetzt klar ist was ich meine.

Was ich im Endeffekt wissen will ist ob Ihr Probleme mit der Art des aufbaus seht die ich vielleicht übersehen habe.

Ein Problem dass z.b. Creator gesehen hat, ist das durchsuchen von so einem Monstrum.
Als Lösung hat er dann forgeschlagen eine Indextabelle zu erstellen die überflüssige wörter nicht speichert und somit leichter ist.
Obwohl es meiner meinung nach fraglich ist um wieviel sie leichter wird. Aber dass ist ein anderes Thema, da ich so eine Index Tabelle jederzeit nachrüsten kann.

nikosch · 21.08.2010, 02:47

Zitat:

ob Ihr Probleme mit der Art des aufbaus seht

Ja. Es scheint absolut umständlich zu sein.

Zitat:

In dieser Tabelle stehen alle namen der DB-Tabellen in dennen sprachvariablen vorkommen können.

Code:

tables
+-----+---------+
| tid | name    |
+-----+---------+
| 1   | laender |
+-----+---------+
| 2   | staedte |
+-----+---------+

Auch mit Beschreibung sehe ich immer noch nicht, was darin stehen soll. Bezeichner wie tid und trid machens auch nicht gerade leichter..

Die Tabelle tables scheint auf jeden Fall der Fehler im Konzept zu sein. Du kriegst doch niemals mit SQL nen dynamischen JOIN gebastelt, wenn die Tabellennamen im Feld stehen.

nikosch · 21.08.2010, 15:00

Langsam verstehe ich, was das werden soll. Schau Dir mal OpenGeoDB an, die benutzen ein Prinzip dieser Art:

Code:

types
ID | type
 1   country
 2   city
 3   
 4   sight
 5   area
 6   population
 7   height


names
ID | type | lang | isNativeLang | description
 1    1      de      1            Deutschland
 1    1      en      0            Germany
 2    1      de      0            Frankreich
47    2      de      0            Paris 
11    4      en      0            Eiffel tower
47    2      de      0            Paris 
 2    1      en      0            France
33    2      de      1            Berlin


references
ID | refID
47    2
33    1
11   47


data
RefID | type | value
 2      6      65447374
47      5      105.4
47      6      2193031
11      7      324.00

.

Die Daten sind dabei nicht ganz atomar. Z.B. die Angabe isNativeLang. Letzten Endes ist das eine Performancefrage, ob man sich immer durch den kompletyten Baum durchhangeln will. Abhängig davon könntest Du unter references eben auch redundant verlinken - statt Eiffelturm - Paris - Frankreich eben auch Eifelturm - Frankreich.

Squall · 21.08.2010, 15:59

Stimmt, mit dem Join hast du recht.
Ich müsste zwei anfragen senden um erstmal die suche durchzuführen und dann noch eine um die restlichen (nicht mehrsprachigen) daten zu holen.

Danke erstmal für eure hilfe, bin jetzt erstmal in Urlaub. Danach werde ich mich nochmal hinsetzten und mir über das Problem mit den Joins gedanken machen und mich hier nochmal mit der Lösung oder neuen Problemen melden.

Danke & Gruß an alle
Squall

phpsecretary · 23.08.2010, 11:08

tabelle_irgendwas
id | txt1 | txt2 | zahl
----------------------
1 | 992 | 213 | 20.35

tabelle_lang
id | lang | txt
----------------------
213 | de | Mahlzeit
213 | en | Cheers
...
992 | de | Prost
992 | en | Cheers

Evtl. Kann man zwei lang Tabellen anlegen, eine "varchar" eine "text"...
Aber da kommen wir schon in den Bereich Wörterbuch...

Squall · 08.10.2010, 13:09

Hab endlich mal wieder Zeit mich hiermit zu beschäftigen.

@nikosch
Sieht ganz gut aus. Ich werde mal versuchen es auf diese Art in mein System einzubauen und melde mich dann zurück.

@phpsecretary
Dieses Shema habe ich schonmal verwendet:

Zitat:

Zitat von Squall

Eine weitere Idee war es die Sprachen zentral zu speichert.

lang_titel

Code:

+-----+---------+---------+
| id  | lang    | titel   |
+-----+---------+---------+
| int | varchar | varchar |
+-----+---------+---------+

lang_text

Code:

+-----+---------+------+
| id  | lang    | text |
+-----+---------+------+
| int | varchar | text |
+-----+---------+------+

irgendeine_tabelle

Code:

+-----+---------------+--------------+
| id  | lang_titel_id | lang_text_id |
+-----+---------------+--------------+
| int | int           | int          |
+-----+---------------+--------------+

Problem:
Als irgendwann eine Suchfunktion zur Debatte stand, musste ich feststellen dass ich über alle Tabellen gehen muss um z.b. herauszufinden wo der lang_text mit der id 5 verknüpft ist. Also auch Schrott!

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Suche] Anpassen von CMS an Design	kelv	Gewerblich	1	27.05.2010 20:33
Design für PHP-Trader	CrashStudios	Beitragsarchiv	0	27.12.2009 22:17
Design Pattern	Harry B.	Software-Design	7	02.09.2008 20:49
Design und Code Trennen	TeazY	PHP Tipps 2008	29	21.05.2008 12:08
Design		Beitragsarchiv	26	04.06.2005 20:56
[PHP] Design Schutz für ein Gästebuch	I-Spy	PHP Tipps 2005	5	01.01.2005 11:25


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

21.08.2010, 15:00
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.248 PHP-Kenntnisse: Fortgeschritten	Langsam verstehe ich, was das werden soll. Schau Dir mal OpenGeoDB an, die benutzen ein Prinzip dieser Art: Code: types ID \| type 1 country 2 city 3 4 sight 5 area 6 population 7 height names ID \| type \| lang \| isNativeLang \| description 1 1 de 1 Deutschland 1 1 en 0 Germany 2 1 de 0 Frankreich 47 2 de 0 Paris 11 4 en 0 Eiffel tower 47 2 de 0 Paris 2 1 en 0 France 33 2 de 1 Berlin references ID \| refID 47 2 33 1 11 47 data RefID \| type \| value 2 6 65447374 47 5 105.4 47 6 2193031 11 7 324.00 . Die Daten sind dabei nicht ganz atomar. Z.B. die Angabe isNativeLang. Letzten Endes ist das eine Performancefrage, ob man sich immer durch den kompletyten Baum durchhangeln will. Abhängig davon könntest Du unter references eben auch redundant verlinken - statt Eiffelturm - Paris - Frankreich eben auch Eifelturm - Frankreich. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

21.08.2010, 15:59
Squall Erfahrener Benutzer Registriert seit: 19.03.2009 Beiträge: 539 PHP-Kenntnisse: Fortgeschritten	Stimmt, mit dem Join hast du recht. Ich müsste zwei anfragen senden um erstmal die suche durchzuführen und dann noch eine um die restlichen (nicht mehrsprachigen) daten zu holen. Danke erstmal für eure hilfe, bin jetzt erstmal in Urlaub. Danach werde ich mich nochmal hinsetzten und mir über das Problem mit den Joins gedanken machen und mich hier nochmal mit der Lösung oder neuen Problemen melden. Danke & Gruß an alle Squall

23.08.2010, 11:08
phpsecretary Erfahrener Benutzer Registriert seit: 14.01.2010 Beiträge: 124 PHP-Kenntnisse: Fortgeschritten	tabelle_irgendwas id \| txt1 \| txt2 \| zahl ---------------------- 1 \| 992 \| 213 \| 20.35 tabelle_lang id \| lang \| txt ---------------------- 213 \| de \| Mahlzeit 213 \| en \| Cheers ... 992 \| de \| Prost 992 \| en \| Cheers Evtl. Kann man zwei lang Tabellen anlegen, eine "varchar" eine "text"... Aber da kommen wir schon in den Bereich Wörterbuch... __________________ Ich bin Programmierer und kein Frameworkinstallierer.