Design einer DB für mehrsprachigkeit

[Squall]

Hallo zusammen,

ich arbeite derzeit an einem CMS-System und bin nun beim Thema mehrsprachigkeit angekommen. In der vergangenheit habe ich bereits mehrsprachigkeit implementiert, bin aber jedesmal auf Probleme gestoßen die zum teil sogar nicht mehr zu bewältigen wahren.

Nachtrag: Die erwähnte mehrsprachigkeit bezieht sich auf die vom user eingegeben Texte und nicht auf die CMS Oberfläche selbst.

Ein Modell das zu jeder sprache den text in separate, den sprachen zugeordneten, felder speichert.

+----+----------+----------+---------+---------+
| id | titel_de | titel_en | text_de | text_en |
+----+----------+----------+---------+---------+

Problem:
Bei größeren projekten ist eine erweiterung der sprachen mit enormen aufwand verbunden.

Eine weitere Idee war es die Sprachen zentral zu speichert.

lang_titel

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

lang_text

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

irgendeine_tabelle

+-----+---------------+--------------+
| 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!

Eine weitere Idee war es für jede Tabelle in der übersetzungstexte auftauchen, eine eigene lang tabelle einzubinden. Diese Konzept habe ich aber nie umgesetzt da es das volumen der DB verdoppel bzw. verdreifachen würde.

Somit stehe ich nun wieder da und überlege wie ich ein sprachenmodell umsetzen soll.

Am liebsten würde ich bei der zentralen speicherung bleiben und diese dann um 2/3 Felder erweitern, in dennen ich speichern kann wo der text verwendet wird.

lang_titel

+-----+---------+---------+---------+-------------+---------------+
| id  | lang    | titel   | tabelle | tabellen_id | tabellen_feld |
+-----+---------+---------+---------+-------------+---------------+
| int | varchar | varchar | varchar | int         | varchar       |
+-----+---------+---------+---------+-------------+---------------+

Somit währe das ganze beliebig um sprachen erweiterbar und sollte mein damaliges Problem mit der Suche abfangen.

Da ich aber nicht wieder auf die schnauze fallen will, dachte ich mir ich Stelle das hier mal zu Diskussion und höre mir eure Ansätze an, sofern ihr diese teilen möchtet.

Über Links die sich mit diesem Thema befassen würde ich mich natürlich auch freuen.

Schönen Gruß
Squall

[chorn]

Mal sowas probiert?

tables
+-----+---------+
| tid | name    |
+-----+---------+
| int | varchar |
+-----+---------+

fields
+-----+-----+----------+
| fid | tid | name     |
+-----+-----+----------+
| int | int | varchar  |
+-----+-----+----------+

langs
+-----+---------+
| lid | name    |
+-----+---------+
| int | varchar |
+-----+---------+

tables_fields_langs_texts
+-----+-----+-----+-----+---------+
| id  | tid | fid | lid | txt     |
+-----+-----+-----+-----+---------+
| int | int | int | int | varchar |
+-----+-----+-----+-----+---------+

[fab]

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!

Und wo ist das Schrott? Mit der richtigen Indizierung sollte das doch kein Problem sein?

[dr.e.]

Schon mal die Foren-Suche bemüht? Dieses Thema haben wir bereits in aller Ausführlichkeit diskutiert.

[Squall]

@chorn
Nein, noch nicht. Die Logik dahinter müsste die selbe mit dem letzten beispiel das ich erwähnte habe sein. Nur ist bei deinem Beispiel der aufbau ordentlicher, ausser ich habe daran etwas missverstanden. Hast du damit schonmal Probleme gehabt oder etwas zu bemängeln?

@fab
Was währe eine "richtige" Indizierung?

@Dr. e.
Habe ich, leider bekomme ich unmengen von Ergebnissen, habe mir einige angeschaut doch leider sind es meistens nur Problem und Lösung Fragen. Mir geht es um die generelle Frage wie sowas aufgebaut wird.

Da das CMS das ich jetzt aufbaue eine Lösung auf dauer sein soll, ist es mir wichtig nicht in einem halben Jahr festzustellen das ich mist gebaut habe. Bin in der Firma der einzige Programmirer, kann meine Lösungen daher leider nicht mit Kollegen durchsprechen und bin eben auf solche Platformen wie hier angewiesen.

[fab]

Ich würde sagen, ausgehend von deiner bestehenden Struktur: Je ein Index auf lang sowie auf lang_text_id und lang_title_id dort wo sie als foreign keys verwendet werden, FULLTEXT Index auf lang_text.text, dann kannst du in lang_text z.B. so suchen:

SELECT irgendeine_tabelle.id FROM lang_text t
LEFT JOIN irgendeine_tabelle cms ON lang_text_id=t.id
WHERE lang='de' AND MATCH (text) AGAINST ('Suchbegriff')

[Asipak]

Hi,

geht dieses Thema in deine Richtung?

http://www.php.de/php-fortgeschritte...t-mit-php.html

[Squall]

Das würde funktionieren solange es nur irgendeine_tabelle gibt. Normalerweise hat man aber irgendeine_tabelle 1 bis X z.b. 30.

Jetzt erweitern wir das SQL-Statement damit es über 30 Tabellen prüft und holen uns einen Kaffee während er sucht. Zusätzlich tut mir der der da nochmal was ändern muss leid

Nachtrag:
@Asipak
leider nicht das verlinkte Thema beschäftigt sich mit der übersetzung der Begriffe die vom Programmierer definiert werden. Mir geht es um das System um Benutzereingaben zu übersetzen. Die eingaben die im ACP getätigt werden.

[fab]

Das würde funktionieren solange es nur irgendeine_tabelle gibt. Normalerweise hat man aber irgendeine_tabelle 1 bis X z.b. 30.

Wenn die alle mit einer einzigen Suche abgegrast werden sollen, ist vielleicht gerade da der Wurm in deinem DB-Design. Was wären das denn z.B. für Tabellen? Und in was für Relationen stehen sie zu den Texten, gehört ein Text zu mehreren "irgendwelchen" Tabellen oder nur jeweils einer?

[cycap]

Warum muss man in einem CMS nach Content-content (dämlicher Begriff, ich weiss ) suchen? Ich sehe da nicht wirklich viel Sinn drin...

[Squall]

Was wären das denn z.B. für Tabellen? Und in was für Relationen stehen sie zu den Texten, gehört ein Text zu mehreren "irgendwelchen" Tabellen oder nur jeweils einer?

Ein Text gehört immer nur zu einer Tabelle und Tabellen kann es beliebig viele geben.

Warum muss man in einem CMS nach Content-content (dämlicher Begriff, ich weiss ) suchen? Ich sehe da nicht wirklich viel Sinn drin...

Jetzt bin ich verwirrt? Im Frontend muss doch der Seitenbesucher nach irgendeinen Begriff suchen können. Hier im Forum ist doch auch eine suche integriert.

[fab]

Beliebig viele Tabellen? Wozu?

Gehört ein Text nur zu einem Eintrag in einer Tabelle, kannst du mit einer 1:1 Relation theoretisch leicht vom Text auf den Eintrag kommen. Allerdings müsstest du dazu Vererbung simulieren, ich bleibe dabei: Dein Problem ist das DB-Design bei den Content-Tabellen oder was auch immer - die Frage, was "irgendeine_tabelle" überhaupt sein kann/soll hast du ja leider nicht beantwortet.

[cycap]

Jetzt bin ich verwirrt? Im Frontend muss doch der Seitenbesucher nach irgendeinen Begriff suchen können.

Ok vielleicht habe ich mich schlecht ausgedrückt, da ich eher ans Backend dachte.

Anders: durchsucht werden muessen doch nur Texte die auch im Frontend dargestellt werden und wenn du eine Tabelle hast in der die Texte alle enthalten sind in allen Sprachen, dann kannst du darin doch suchen? An welcher Stelle du den eigentlichen Text dann verwendest, das ist doch egal. Angenommen du hast eine Tabelle fuer Produkte und eine fuer News. Wenn nun beide Tabellen keine Texte mehr enthalten sondern auf deine Uebersetzungstabelle referenzieren, dann kannst du doch wunderbar suchen?

[Squall]

Ich glaube wir drehen uns im Kreis

Hier mal ein sinnloses aber hoffentlich einfach zu verstehendes Beispiel

Folgende Tabellen:

- Texte für seite 1
- Texte für seite 2
- Texte für seite 3
- Texte für seite 4
- Texte für seite 5
- Texte für seite 6
- Texte für seite 7
- Texte für seite 8
- Texte für seite 9

Auf der Startseite gibt es 9 Links, jeder Link führt zu einer unterseite die sich die inhalte aus ihrer DB-Tabelle holt. Der Link "Seite 1" holt sich die aus "Texte für seite 1", der Link "Seite 2" holt sich die aus "Texte für seite 2" etc.)

Jetzt kann der user noch irgendwie seine sprache wählen und gut ist.

Problem meiner alten Sprachensteuerung lag daran das bei einer suche in der sprachen Tabelle ich zwar ergebnisse hatte diese aber nur mühsam zuordnen konnte da es in der Sprachtabelle keine backlinks gab. Dieses Problem hat sich ja mit dem Besipiel von chorn:

tables
+-----+---------+
| tid | name    |
+-----+---------+
| int | varchar |
+-----+---------+

fields
+-----+-----+----------+
| fid | tid | name     |
+-----+-----+----------+
| int | int | varchar  |
+-----+-----+----------+

langs
+-----+---------+
| lid | name    |
+-----+---------+
| int | varchar |
+-----+---------+

tables_fields_langs_texts
+-----+-----+-----+-----+---------+
| id  | tid | fid | lid | txt     |
+-----+-----+-----+-----+---------+
| int | int | int | int | varchar |
+-----+-----+-----+-----+---------+

erledigt. Darauß resultiert für mich eben nur noch die Frage, ob sich mit dieser Struktur andere Probleme ergeben oder es noch bessere/andere Lösungen gibt. Wie schon erwähnt bin ich mit Sprachen schon 2 mal auf die Fresse geflogen und würde es daher gerne diesmal vermeiden.

[Creator]

Selbst hier stelle ich mir die Suche sehr mühselig vor. Grade wenn du viel Text hast. Was es durchaus ja geben soll, möchte ich dieses nicht mit z.B. Like durchlaufen.
Für die Suche würde ich mir was eigenes Programmieren.
Und zwar in dem du dir einen wirklichen Suchindex erstellst und diesen mit dem Content verbindest. Nur so erreicht man auch verdammt schnell suchergebnisse.
Stell dir mal vor du hast ein Forum mit nur 1000 Beiträgen. Möchtest in deiner Suche aber eine Art Autocompletefunktion mit einbauen. Viel spaß.