Mehrsprachige Filmdatenbank

[lauder]

Ich wusste nicht so recht wohin mit dem Thema, darum habe ich mal Datenbanken genommen.

Ich zermürbe mir den Kopf gerade über folgende Sache:
Ich arbeite an einer Film-Datenbank, bei der man einiges an Infos zu den jewiligen Filmen auslesen kann. So weit so gut, nur mache ich mir die ganze Zeit Gedanken darüber, wie man die Datenbank am besten organisieren kann, um die Einträge dann in mehreren Sprachen anzeigen zu lassen.

Ich habe schon einige Ideen, wie z.B. einzelne Infos wie z.B. Genres, Erscheinungsjahr etc. in externe Tabellen auszulagern, denn momentan sind die meisten Infos in einer Tabelle, aber doppelte Einträge würde ich gerne vermeiden. Das Problem: Würde ich die Infos in externe Tabellen auslagern, hätte ich extrem viele Tabllen und müssten mit sehr viele Joins in den Querys arbeiten, was nicht gerade Ressourcensparend wäre.

Ich habe noch einige andere Ideen, würde mir an dieser Stelle aber gerne ein paar Ratschläge oder sogar eine 'richtige' Lösung geben lassen.

[Gast]

http://v.hdm-stuttgart.de/~riekert/l...kelz/chap4.htm

[lauder]

Danke für deine Antwort, auch wenn sie relativ knapp ausfällt.
Ich habe mir das alles jetzt 2-3 mal durchgelesen, habe aber nach wie vor die gleichen Fragen.

[achtelpetit]

...hätte ich extrem viele Tabllen und müssten mit sehr viele Joins in den Querys arbeiten...

Eben das ist das Wesen einer (relationalen) Datenbank; Tabellen kosten nix. Du mußt auf einwandfreie Schlüsselfelder achten, dann kosten die Joins auch nicht viel; auf jeden Fall die Primärschlüssel immer aus Integers bilden.
Mach' Dir 'ne Skizze mit Bleistift und Papier und fang dann erst an die DB zu bauen.

[lauder]

Das ist mein 1. Projekt in dieser Grössenordnung und ich arbeite ganz alleine daran. Zwar lese ich mich durch viele Lektüren durch, aber Theorie und Praktik sind 2 unterschiedliche Welten. Nun, wenn das mit den vielen Tabellen keine abstrakte Datenbankstrukturierung ist, wie ich es zuerst dachte, dann danke ich für die Antworten und werde das so umsetzen.

[ChristianK]

Eben das ist das Wesen einer (relationalen) Datenbank; Tabellen kosten nix. Du mußt auf einwandfreie Schlüsselfelder achten, dann kosten die Joins auch nicht viel; auf jeden Fall die Primärschlüssel immer aus Integers bilden.

Mach' Dir 'ne Skizze mit Bleistift und Papier und fang dann erst an die DB zu bauen.

Das würde ich so nicht unterschreiben. Extrem viele Tabellen kann ja auch 1000, 2000, 10000... bedeuten. Und da stellt sich dann schon die Frage, wo der Sinn der Sache liegt. Extrem viele Tabellen kann ja auch bedeuten, dass er für jedes Genre eine eigene Tabelle macht.

Wichtig ist, dass du auf die Normalformen achtest und so gut wie sinnvoll und möglich normalisierst.

Ansonsten hat er recht, Informationen aus zwei oder mehreren Tabellen hast du mittels Joins und Indexes sehr kostensparend geholt.

[lauder]

Das Problem besteht bei mir halt eben, wie schon anfangs erwähnt, in der Übersetzung. Zum Beispiel Sachen wie die Saison:

-Frühling
-Sommer
-Herbst
-Winter

Und das muss ich dann in allen Sprachen übersetzen.
Es sind also immer kleine Datensätze.. Es werden aber keineswegs 2000 Tabellen. Im Endeffekt sind es vielleicht 15-20 Tabellen mehr als im Moment.

[rkr]

Normalisierung. Du hast dann pro Übersetzung einen Datensatz. Nicht eine Tabelle.

[lauder]

Normalisierung. Du hast dann pro Übersetzung einen Datensatz. Nicht eine Tabelle.

Wie soll ich das verstehen?

[akretschmer]

Wie soll ich das verstehen?

Ganz einfach: google nach Datenbank-Normalisierung, lies die Treffer.

[lauder]

Ich weiss das ich nicht pro Übersetzung eine Tabelle habe.
Allerdings pro Datensatz... Das Problem ist nur, ich hätte zum gleichen Film, in sagen wir mal 3 verschiedenen Sprachen, die gleichen Genres aufgelistet. Da lohnt es sich glaube ich mehr, dass mit Sprachdateien zu übersetzen.

[rkr]

Eher nicht. Du hast für den Film einen Stammdatensatz und für die Sprachdaten jeweils referenzierende Datensätze in einer weiteren Tabelle.

[lauder]

Eher nicht. Du hast für den Film einen Stammdatensatz und für die Sprachdaten jeweils referenzierende Datensätze in einer weiteren Tabelle.

Ich habe das Gefühl, dass wir aneinander vorbei schreiben...
Ich sehe das Problem folgendermassen:

Als Beispiel nehme ich die Tabelle Genres.
Jetzt schreibe ich also in die Deutsche Version folgendes in die Datenbank:
Liebeskomödie, Abenteuer
Das refferenziere ich dann natürlich auf die Stammdaten, wo Informationen drin stehen wie Jahrgang, Bewertung etc.

Nun stellt einer die Seite um auf Englisch, also muss ich die Genres auf Englisch ausgeben.
Das heisst also, ich muss die Genres nun noch einmal eintragen, allerdings auf Englisch:
Love, Comedy, Adventure

Somit hätte ich mehr oder weniger den gleichen Datensatz doppelt.
Darum frage ich mich gerade, ob ich den Genres nicht einfach eine Nummer zuordnen sollte und dann mit Sprachdateien arbeiten sollte.

[Tropi]

Darum frage ich mich gerade, ob ich den Genres nicht einfach eine Nummer zuordnen sollte und dann mit Sprachdateien arbeiten sollte.

Die Genres HABEN ja eine Nummer. Den Primärschlüssel der Tabelle `genres`.
Ganz allgemein: Jedes mal wo du eine sprachabhängige Bezeichnung brauchst, hast du stattdessen einen Fremdschlüssel zu dieser Tabelle. Also z.B. Genres, Filmtitel, etc.

[lauder]

Die Genres HABEN ja eine Nummer. Den Primärschlüssel der Tabelle `genres`.
Ganz allgemein: Jedes mal wo du eine sprachabhängige Bezeichnung brauchst, hast du stattdessen einen Fremdschlüssel zu dieser Tabelle. Also z.B. Genres, Filmtitel, etc.

Sorry wenn ich etwas schwerbegrifflich wirke, aber nochmal um sicher zu gehen:

Ich soll also eine Tablle erstellen, die in etwa so aussieht:
id | Genre | language

Da schreibe ich dann z.B. "Abenteuer" rein und vergebe dafür die id 1.
Dann schreibe ich "Abenteuer" in mehreren Sprachen, vergebe dafür natürlich den jeweils richtigen Ländercode und steht's die id 1.

Danach verbinde ich die Genres in der Haupttabelle, die jeweils als id angegeben werden, mit der Tabelle der Genres, natürlich mit der jeweils richtigen Sprache.
Ist das so richtig?