Ich habe mehrere Datentabelle dessen Text in unterschiedlichen Sprachen dargestellt werden sollen.
z.b.
[sql]CREATE TABLE IF NOT EXISTS language ( id int(11) NOT NULL AUTO_INCREMENT, created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, created_by int(11) NOT NULL, published tinyint(1) NOT NULL DEFAULT ‘1’, deleted tinyint(1) NOT NULL DEFAULT ‘0’, name varchar(255) NOT NULL, iso varchar(255),
PRIMARY KEY (id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS Country ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(255) NOT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE TABLE IF NOT EXISTS EineAndereDatenTabelle ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(255) NOT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
[/sql]
Die Datenfelder ‘name’ von datatable1 soll sprachabhängig sein. Sprich für Country könnte z.B. das Land für Deutschland ‘Deutschland’, ‘Germany’, ‘Alagmane’ sein.
Die Tabelle EineAndereDatenTabelle könnte z.B. für ‘name’ andere unterschieldiche, sprachabhängige Werte in der Datentabelle enthaltne.
Wie könnte ich soetwas am besten in einer Datentabelle abbilden?
Soll das Feld ‘name’ sprachabhängig anders heißen oder sollen die darin Werte in verschiedenen Sprachen gespeichert werden?
Ich verstehe nicht so ganz, worauf Deine Frage eigentlich abzielt !
Versuch’ es vlt. mal mit einem konkreten Beispiel zu erklären!
CREATE TABLE IF NOT EXISTS Translation ( id int(11) NOT NULL AUTO_INCREMENT, table_name varchar(255) NOT NULL, attribute_name varchar(255) NOT NULL, language_id_iso varchar(5) NOT NULL, localized_pattern varchar(255) NOT NULL,
) ENGINE=InnoDB DEFAULT CHARSET=latin1; [/SQL] table_name,attribute_name und language_id_iso sind dabei uniqe.
Diese Tabelle muss dann für jedes zu übersetztende Attribut ein mal mit in die Abfrage aufgenommen werden.
Die eigentliche Übersetzung heißt „Pattern“ weil es durchaus möglich ist, dass Du beispielsweise ein Datum in der landestypischen Weise anzeigen willst, was mit statischem Text schlecht geht…
Ich bin gerad an einem kleine Projekt dabei, welches mehrsprachig werden soll. Es existieren mehreren Tabellen, die mehrsrpachige Einträge haben sollen.
hier mal symbolisch eine kleines Beispiel dargestellt.
Tabelle: Language
ID (Primary Key)
name
Tabelle: Bundesland
ID (Primery Key)
lang_id (ID zur Language Tabelle)
Land (ID zum Land)
Name
Tabelle: Land
ID (Primery Key)
lang_id (ID zur Language Tabelle)
Name
Tabelle: Person
ID (Primery Key)
Name
Anschrift
Bundesland (ID zum Bundesland)
Land (ID zum Land)
Personentabelle beinhaltet pro Person nur einen Eintrag. Somit müsste es auch ein eindeutige ID auf ein Bundesland und Land geben.
Jetzt stelle ich z.B. die Ansicht auf eine andere Sprache um und frage die gleiche Person ab. Eine ID auf ein Bundesland oder Land ändert sich ja nicht. Aber denoch müssten das Land oder Bundesland den “andersprachigen” Namen zurückliefern.
Ich könnte natürlich aus dem Primären Key einen selbstgenerieren Key machen. Aber ist dieses sinnvoll bzw. wie würdet ihr so ein Problem lösen?
[quote=Timothy_Truckle;106248]Die übliche vorgehensweise ist eine Tabelle „Translations“:
SQL Code:
*
CREATE TABLE IF NOT EXISTS Translation (
*id int(11) NOT NULL AUTO_INCREMENT,
*table_name varchar(255) NOT NULL,
*attribute_name varchar(255) NOT NULL,
*language_id_iso varchar(5) NOT NULL,
*localized_pattern varchar(255) NOT NULL,
) ENGINE=InnoDB *DEFAULT CHARSET=latin1; table_name,attribute_name und language_id_iso sind dabei uniqe.[/quote]
Hm, diese vorgehensweise finde ich weder üblich noch besonders geschickt.
Diese Tabelle muss dann für jedes zu übersetztende Attribut ein mal mit in die Abfrage aufgenommen werden.
Und den Grund lieferst du passenderweise gleich mit
Folgendes Schema finde ich da schon besser:
[SQL]
CREATE TABLE country (
id int(11) NOT NULL AUTO_INCREMENT,
created_by …,
created_at …,
PRIMARY KEY (id)
)
CREATE TABLE country_i18n (
country_id int(11) NOT NULL,
language_id int(11) NOT NULL,
name varchar(255) NOT NULL,
description text NOT NULL,
PRIMARY KEY(country_id, language_id)
)
[/SQL]
Das hätte den Vorteil, dass eine Sprachabhängige Abfrage so aussehen kann:
[SQL]
SELECT c.country_id, ci18n.name, ci18n.description
FROM country AS c
INNER JOIN country_i18n AS ci18n
ON (c.language_id = c.language_id)
WHERE ci18n.language_id =
[/SQL]
Eine vergleichbare Abfrage wäre mit deinem Schema komplizierter.
als Mischmasch von den beiden bisherigen vielleicht noch einen Blick wert:
TABLE Dictionary
id,
reference_name, // hauptsächlich für bessere Übersicht, Id würde reichen, oder dies hier als Id verwenden
genau n Einträge für n Sprachen, nicht unbedingt immer gesetzt,
oder hier nix weiter und je eine Tabelle pro neuer Sprache
oder hier nix weiter und dynamisch eine Tabelle mit beliebig vielen Einträgen als Kombinationen von Dictionary-Id, Sprache, Wert,
vergleichbar country_i18n aber allgemein dictionary_i18n
in der Tabelle Country wie in jeder andere könnte dann an jeder Stelle von String-Attributen stattdessen eine Id-Referenz auf einen Dictionary-Eintrag bestehen,
vielleicht zur besseren Lesbarkeit auf String belassen und stattdessse den reference_name, Fremdschlüssel-Check geht mit beidem
innerhalb von SQL dann für jede Spalte joinen will man sicher nicht,
Suche, Sortierung usw. bestimmt beschränkt bis untauglich zu handhaben,
aber in Java geladen wäre Austausch gegen komplett gecachtes Dictionary schon eher machbar
[quote=SlaterB]als Mischmasch von den beiden bisherigen vielleicht noch einen Blick wert:
TABLE Dictionary
id,[/quote]Das sollte die ID des Übersetzungsdatensatzes sein, damit man den später besser Pflegen kann.
[quote=SlaterB;106261]- reference_name,[/quote] das sollte die ID des zu übersetztenden Elements sein.
[quote=SlaterB;106261]+ genau n Einträge für n Sprachen, nicht unbedingt immer gesetzt,[/quote]Mach sinn, dass sieht man sehr gut, in welcher Sprache noch übersetzungen fehlen…
