Datenbankentwurf so ok?

28.06.2011, 19:43

Hallo zusammen,

ich bin gerade dabei eine Webseite zu aktualisieren. Entwürfe sind hier zu sehen:

http://www.romaniuk.de/entwurf/entwurf-2-1.jpg
http://www.romaniuk.de/entwurf/entwurf-2-2.jpg
http://www.romaniuk.de/entwurf/entwurf-2-3.jpg

Dazu habe ich einen Datenbankentwurf erstellt, welchen ihr hier sehen könnt:

http://www.romaniuk.de/entwurf/db.jpg

Das ganze soll so ausschauen:

Auf der ersten Seite muss man die Rubriken auswählen. Die Unterteilungen in der Navi gelten gleichzeitig als Rubrik (ich wollte dafür nicht extra noch eine Tabelle machen). Hier wählt man diese aus. Danach kommt man zur Übersichtsseite (Entwurf 2). Diese wird unter allen Rubriken gleich sein. Hier werden zudem rechts die Kategorien der Rubrik zu sehen sein, nach denen man auch sortieren kann. Auch werden die generell letzten Beiträge aufgelistet.

Nach Auswahl eines Beitrages kommt man auf die Seite der Slideshow (Entwurf 3), wo die Bilder ausgegeben werden.

Was hier noch nicht zu sehen ist: Die Seite wird einmal in einer deutschen und einer polnischen Version zu sehen sein (de, pl).

Da die Inhalte der Beiträge immer gleich sind, werden die Beiträge der einzelnen Beiträge in eine Tabelle geschrieben (bilder_uebersicht). Das macht auch die Ausgabe nach Zeitpunkt der Erstellung einfacher. In bilder kommen die einzelnen Bilder, welchen ein Erklärungstext zugeordnet wird. diese werden über den Fremdschlüssel bilder_uebersicht_id zugeordnet.

Die Navigation (navigation) fungiert gleichzeitig für das navigationsmenü als auch für die Rubriken.

Das Herzstück ist dann kategorie_bild_uebersicht_verbindung-Tabelle, wlche die Beitragsübersicht, die Bilder und Kategorien mit einander verknüpft. Ich habe die Kategorien auch deswegen dieser zugeordnet, da es verschiedene Kategorien mit den gleichen Namen geben kann (z.B. kann es einmal Landschaft als Kategorie bei den Fotos als auch in der Malerei geben). So habe ich diese aber eindeutig einer Rubrik zugeordnet.

index_text ist dann noch für den Begrüßungstext auf der Index-Seite.

Ich bibn mir aber noch nicht 100% sicher, wie ich die Kategorien, Rubriken und Bilder mit einander verknüpfen soll. Eine andere Möglichkeit wäre natürlich noch die bilder_id mit in die Verbindungstabelle zu nehmen und das darüber aufzulösen.

Könnt ihr mal drüber schauen ob der Ansatz so ok ist?

NACHTRAG: Ich habe den Spalte bilder_uebersicht_id aus bilder rausgenommen und in der kategorie_bilder_uebersicht_verbindung-tabelle die Spalte bilder_id zugefügt. Somit ist ersteres nicht mehr dopelt und ich könnte alles über die Verbindungstabelle lösen...

Besten dank

Lapje

Maxefix · 29.06.2011, 09:58

Ich würde für jede m:n-Verknüpfung eine eigene Tabelle erstellen, und zwar mit dem Namen "tabelle1_tabelle2" und nur den Feldern "tabelle1_id" und "tabelle2_id". Der Primary-Key geht dann über beide Spalten.

Was steht in den Feldern "vorschaubild" in "bilder_uebersicht" und "bild" in "navigation"? Und warum speicherst du die ID des Bildes nicht in "bilder_uebersicht"? Würde sich doch anbieten, dann kannst du rein theoretisch ein Bild mehrfach verwenden.

Ich würde übrigens englische Begriffe verwenden. Die versteht wirklich jeder, auch ein polnischer Entwickler.

bilder_uebersicht -> posts
bilder -> images
kategorie -> categories
navigation -> navigation
index_text -> index
kategorie_bilder_uebersicht_verbindung -> categories_posts und categories_navigation

Wie speicherst du die Bilder eigentlich? In der Bilder-Tabelle gibt es kein Feld für den Dateinamen oder verwendest du einfach die ID? Wäre aber problematisch, da du die Dateierweiterung ja nicht weißt.

Gruß,
Max

29.06.2011, 10:30

erst mal besten dank...

stimmt, den Bildernamen habe ich ganz vergessen....ich Schussel..

Ich würde die Bilder lieber lieber in einer eigenen Tabelle speichern, da das ganze ansonsten doch recht unüberichtlich wird.

Das mit den Namen ist schon ok so, da nur ich die Page nacher bearbeiten werde (ist die Page meiner Frau..

)

Wenn ich Dich richtig verstanden habe soll ich dann mehrere Verbindungstabellen machen? Also eine einzelne für die Kategorien, und für die navigation, usw? Kannst Du mir erklären warum - nur damit ich verstehe warum. Ich dachte nämlich dass es übersichtlicher wäre und die Abfragen einfacher zu erstellen wären wenn ich es in einer mache. Zumal die Abfragen auf jeder Seite gebraucht werden (Wenn die Übersichts- und die Bilderseite aufgerufen wird, werden die Kategorien aufgerufen, welche auch von der Rubrik abhängig sind, da es z.B. eine Kategorie Landschaft sowohl bei den Fotos als auch in der Malerei geben kann, welche aber unabhängig von einander sind. Dieses müssen dann ja den Bildern zugeordnet werden...also irgendwie gehört das ja alles zusammen...

Besten dank für die Mühe...

Lapje

Trainmaster · 29.06.2011, 10:57

Zitat:

Zitat von Lapje

Was hier noch nicht zu sehen ist: Die Seite wird einmal in einer deutschen und einer polnischen Version zu sehen sein (de, pl).

An dieser Stelle sollte Normalisierung zum Einsatz kommen, anstatt für jede Sprache extra Spalten hinzuzufügen. Dieses Thema ist hier schon mehrfach diskutiert worden, z.B.:

http://www.php.de/datenbanken/76373-...rsprachig.html (Konzept - Texte mehrsprachig)

http://www.php.de/datenbanken/76000-...h-tabelle.html (Zweisprachige Webseite (Datenbankfrage bezüglich Tabelle))

http://www.php.de/datenbanken/68797-...-webseite.html (Welcher Tabellen Aufbau ist besser (mehrspr. Webseite))

29.06.2011, 11:14

ok, was ich auf der schnelle lesen konnte sollte ich lieber für jede SPrache eine Tabelle machen, richtig? Was aber auch bedeuten würde, dass ich für jede Tabelle, in der verschiedene Sprachen sind, evt. 3 brauche....also bei bilder_uebersicht wären dass dann bilder_uebersicht_de ,bilder_uebersicht_pl und bilder_uebersicht für die restlichen Sachen...Oder ist das so gemeint, das zwei grundsätzliche Tabellen für alle Inhalte in den Sprachen angelegt werden, welche dann über IDs (z.B. sprache_pl_id mit der ID=1 ist für alle Texte, die in der polnischen Version in der Übersicht stehen, ID=2 für die deutschen Texte dort usw...)

Ist das so gedacht?

Ich dachte immer das es bei der Normalisierung darum geht, redundante Inhalte auszuschließen (z.B. das nirgendwo 5 mal der gleiche Ort auftaucht oder so). Das ist hier ja nicht gegeben, da in den Textinhalten ja immer verschiedene Dinge stehen und auch überall Text reingeschrieben wird (es wird also keine NULL-Felder geben). Zudem dachte ich dass es auch für die Abfrage einfacher und schneller ist, wenn alles aus einer Tabelle kommt...

Ich bezweifle nicht was ihr sagt, nicht dass wir uns da falsch verstehen, es geht mir nur ums verstehen. Ich will ja nicht einfach irgendwas abschreiben, sondern ich will es auch anwenden können...

KarlEgon · 29.06.2011, 11:21

Nicht für jede Sprache eine eigene Tabelle, sondern eine Tabelle für Sprachen, welche du dann mit den Inhalten verknüpfen kannst

29.06.2011, 11:41

ok, dann würde das dann so ausschauen:

(als Beispiel)

Tabelle texte
bilder_uebersicht_ueberschrift_de
bilder_uebersicht_ueberschrift_pl
bilder_uebersicht_text_teaser_de
bilder_uebersicht_text_teaser_pl
bilder_text_de
bilder_text_pl
kategorie_name_de
kategorie_name_pl
navigation_name_de
navigation_name_pl

So?

Aber da riskiere ich doch NULL -Einträge, oder? Ist dass denn dann ok? Denn nicht jedesmal wenn ich eine Kategorie anlege kommen auch Inhalte von Bildern dazu...

Oder für die jeweils einzelnen Tabellen eine einzelne Tabelle für die Sprache?

z.B.

bilder_uebersicht_id
bilder_uebersicht_datum
bilder_uebersicht_vorschaubild
bilder_uebersicht_status
bilder_uebersicht_link
bilder_uebersicht_zeitstempel

und dann eine Tabelle mit den Inhalten:
bilder_uebersicht_inhalt_ueberschrift_de
bilder_uebersicht_inhalt_ueberschrift_pl
bilder_uebersicht_inhalt_text_de
bilder_uebersicht_inhalt_text_pl

Oder so?

Nur dadurch wird die Abfrage doch wesentlich aufwendiger, oder?

Kann mir jetzt noch mal jemand erklären, wo genau die Normalisierung verletzt wird? Es entstehen doch keine redundanten Daten. Klar kann die Normalisierung immer weiter führen, aber würde hier nicht aufgrund der mehreren Tabellen nicht die performance leiden und würde das nicht übersichtlicher werden? Mal von der Fehleranfälligkeit abgesehen...

Maxefix · 29.06.2011, 11:51

Da es bei den zwei Sprachen höchstwahrscheinlich bleiben wird finde ich die jetzige Lösung schon OK. Es ist einfach und zielführend.

Für jede Sprache eine extra Tabelle halte ich in dem Fall für nicht so gut. Die beiden Sprachversionen haben ja 1:1 den gleichen Inhalt, so wie ich das verstanden habe. Wenn du jetzt aber die Tabellen auseinander reißt kann es dir leicht passieren, dass die Datensätze unterschiedliche IDs haben, wodurch eine Zuordnung (Deutscher Datensatz <-> Polnischer Datensatz) erschwert wird. Außerdem musst du sämtliche Strukturänderungen doppelt vornehmen -> Wartungsunfreundlich.

Eine Verknüpfungstabelle hat ja den Sinn eine m:n-Relation abzubilden. Das heißt jeder Eintrag kann mit beliebig vielen anderen Einträgen verknüpft sein.

Durch die Abfrage der Verknüpfungstabelle willst du also rausfinden, mit welchen Datensätzen aus Tabelle B der Datensatz mit der ID 123 aus Tabelle A verknüpft ist.

Beispiel:

Code:

mysql> select * from example_table where tabelle_a_id = 123;
+--------------+--------------+
| tabelle_a_id | tabelle_b_id |
+--------------+--------------+
| 123          | 2            |
| 123          | 5            |
| 123          | 63           |
| 123          | 352          |
| 123          | 410          |
+--------------+--------------+

Bedeutet du weißt nicht wieviele Einträge zurück kommen. Der Datensatz kann ja nur mit einem anderen verknüpft sein, aber auch mit mehreren tausend.

Du kannst jetzt natürlich noch eine Spalte für Tabelle C einfügen. Da die Verknüpfungen aber unabhängig von Tabelle B sind (der Datensatz kann 5 Datensätze aus B und 20 aus C zugewiesen haben), musst du die Verknüpfungen also eh in extra Zeilen speichern. Beispiel:

Code:

mysql> select * from example_table where tabelle_a_id = 123;
+--------------+--------------+--------------+
| tabelle_a_id | tabelle_b_id | tabelle_c_id |
+--------------+--------------+--------------+
| 123          | 2            | NULL         |
| 123          | 5            | NULL         |
| 123          | 63           | NULL         |
| 123          | 352          | NULL         |
| 123          | 410          | NULL         |
| 123          | NULL         | 34           |
| 123          | NULL         | 42           |
+--------------+--------------+--------------+

Du sparst dir also ansich nichts, aber es wird tendenziell eher unübersichtlicher. Darum macht es Sinn die Tabellen zu trennen.

Ist vielleicht etwas umständlich erklärt, aber ich hoff du verstehst auf was ich hinaus will.

Gruß,
Max

29.06.2011, 12:54

@Maxefix

Das ist ja das was ich meinte...

Die Inhalte werden immer gleich angeordnet, sprich: Zu jedem Eintrag gibt es einen deutschen und einen polnischen Teil. Zu jedem eintrag (z.B. unter Fotos) gibt es auch nur eine dazugehörige Bilderserie. Und auch jedes Foto kann/soll nur einer Serie zugeordnet werden, eine Serie enthält aber mehrere Bilder, was ja so erst mal kein Problem ist.

Die einzigen Mehrfachverbindungen sind hier die Kategorien: Eine Bilderserie kann mehrere Kategorien beinhalten (z.B. Landschaft, Meer), eine Kategorie wird aber auch mehrere Bilderserien beinhalten.

Genauso hängen aber auch die Rubriken (welche ich über die Navigation auflöse) und die Kategorien zusammen: Eine Rubrik kann mehrere Kategorien beinhalten, eine Kategorie soll aber nur einer Rubrik zugeordnet werden (Fotografien von Landschaften sind ja etwas anderes als Malereien von Landschaften). Trotzdem denke ich ist es einfacher (auch für die Abfrage) wenn alles in eienr Verbindungstabelle ist.

Auch sehe ich es wie Du, dass durch mehrere Tabellen und veschiedene Abfragen die Gefahr grlßer ist, dass Abfragen sich verkomplizieren und sich Fehler einschleichten, die dann auch wieder schwerer zu erkennen sind.

Nicht das wir uns falsch verstehen: Ich will allen anderen postern nicht widersprechen, das sind nur Gedanken die mir dabei kommen, da die Normalisierung ja redundante Daten verhindern soll, nur die sehe ich hier nicht (was nichts heißen soll)...

Wenn aber jetzt z.B. in den Sprachen unterschiedliche Texte kommen würden (auch zu verschiedenen Zeitpunkten) und nicht alles in beiden Sprachen verfügbar ist, dann wäre die Lösung natürlich nicht optimal...

Trainmaster · 29.06.2011, 14:20

Zitat:

Zitat von Lapje

und nicht alles in beiden Sprachen verfügbar ist.

Ein Grund, der für eine generische Implementierung von Mehrsprachigkeit spricht. Sprachunabhängige Felder (z.B. Datum, Ids, Bool) in eine Tabelle und sprachabhängige Felder (Überschrift, Beschreibung, Text, URL-Abbildung) in eine Übersetzungstabelle. Natürlich kommst du mit deinem Entwurf aus Beitrag #1 auch zum Ziele, doch du raubst dir damit Flexibilität.

Ein Beispiel:

Code:

Tabelle "content"
id | created_at | updated_at

Tabelle "content_translation"
id | lang_id | content_id | text | url_path

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
[Erledigt] Probleme Datenbankentwurf Tippspiel		Datenbanken	1	28.01.2005 14:33

28.06.2011, 19:43
Lapje Gast Beiträge: n/a	Datenbankentwurf so ok? Hallo zusammen, ich bin gerade dabei eine Webseite zu aktualisieren. Entwürfe sind hier zu sehen: http://www.romaniuk.de/entwurf/entwurf-2-1.jpg http://www.romaniuk.de/entwurf/entwurf-2-2.jpg http://www.romaniuk.de/entwurf/entwurf-2-3.jpg Dazu habe ich einen Datenbankentwurf erstellt, welchen ihr hier sehen könnt: http://www.romaniuk.de/entwurf/db.jpg Das ganze soll so ausschauen: Auf der ersten Seite muss man die Rubriken auswählen. Die Unterteilungen in der Navi gelten gleichzeitig als Rubrik (ich wollte dafür nicht extra noch eine Tabelle machen). Hier wählt man diese aus. Danach kommt man zur Übersichtsseite (Entwurf 2). Diese wird unter allen Rubriken gleich sein. Hier werden zudem rechts die Kategorien der Rubrik zu sehen sein, nach denen man auch sortieren kann. Auch werden die generell letzten Beiträge aufgelistet. Nach Auswahl eines Beitrages kommt man auf die Seite der Slideshow (Entwurf 3), wo die Bilder ausgegeben werden. Was hier noch nicht zu sehen ist: Die Seite wird einmal in einer deutschen und einer polnischen Version zu sehen sein (de, pl). Da die Inhalte der Beiträge immer gleich sind, werden die Beiträge der einzelnen Beiträge in eine Tabelle geschrieben (bilder_uebersicht). Das macht auch die Ausgabe nach Zeitpunkt der Erstellung einfacher. In bilder kommen die einzelnen Bilder, welchen ein Erklärungstext zugeordnet wird. diese werden über den Fremdschlüssel bilder_uebersicht_id zugeordnet. Die Navigation (navigation) fungiert gleichzeitig für das navigationsmenü als auch für die Rubriken. Das Herzstück ist dann kategorie_bild_uebersicht_verbindung-Tabelle, wlche die Beitragsübersicht, die Bilder und Kategorien mit einander verknüpft. Ich habe die Kategorien auch deswegen dieser zugeordnet, da es verschiedene Kategorien mit den gleichen Namen geben kann (z.B. kann es einmal Landschaft als Kategorie bei den Fotos als auch in der Malerei geben). So habe ich diese aber eindeutig einer Rubrik zugeordnet. index_text ist dann noch für den Begrüßungstext auf der Index-Seite. Ich bibn mir aber noch nicht 100% sicher, wie ich die Kategorien, Rubriken und Bilder mit einander verknüpfen soll. Eine andere Möglichkeit wäre natürlich noch die bilder_id mit in die Verbindungstabelle zu nehmen und das darüber aufzulösen. Könnt ihr mal drüber schauen ob der Ansatz so ok ist? NACHTRAG: Ich habe den Spalte bilder_uebersicht_id aus bilder rausgenommen und in der kategorie_bilder_uebersicht_verbindung-tabelle die Spalte bilder_id zugefügt. Somit ist ersteres nicht mehr dopelt und ich könnte alles über die Verbindungstabelle lösen... Besten dank Lapje Geändert von Lapje (28.06.2011 um 21:40 Uhr).


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

29.06.2011, 09:58
Maxefix Benutzer Registriert seit: 25.03.2011 Beiträge: 52 PHP-Kenntnisse: Fortgeschritten	Ich würde für jede m:n-Verknüpfung eine eigene Tabelle erstellen, und zwar mit dem Namen "tabelle1_tabelle2" und nur den Feldern "tabelle1_id" und "tabelle2_id". Der Primary-Key geht dann über beide Spalten. Was steht in den Feldern "vorschaubild" in "bilder_uebersicht" und "bild" in "navigation"? Und warum speicherst du die ID des Bildes nicht in "bilder_uebersicht"? Würde sich doch anbieten, dann kannst du rein theoretisch ein Bild mehrfach verwenden. Ich würde übrigens englische Begriffe verwenden. Die versteht wirklich jeder, auch ein polnischer Entwickler. bilder_uebersicht -> posts bilder -> images kategorie -> categories navigation -> navigation index_text -> index kategorie_bilder_uebersicht_verbindung -> categories_posts und categories_navigation Wie speicherst du die Bilder eigentlich? In der Bilder-Tabelle gibt es kein Feld für den Dateinamen oder verwendest du einfach die ID? Wäre aber problematisch, da du die Dateierweiterung ja nicht weißt. Gruß, Max

29.06.2011, 10:30
Lapje Gast Beiträge: n/a	erst mal besten dank... stimmt, den Bildernamen habe ich ganz vergessen....ich Schussel.. Ich würde die Bilder lieber lieber in einer eigenen Tabelle speichern, da das ganze ansonsten doch recht unüberichtlich wird. Das mit den Namen ist schon ok so, da nur ich die Page nacher bearbeiten werde (ist die Page meiner Frau.. ) Wenn ich Dich richtig verstanden habe soll ich dann mehrere Verbindungstabellen machen? Also eine einzelne für die Kategorien, und für die navigation, usw? Kannst Du mir erklären warum - nur damit ich verstehe warum. Ich dachte nämlich dass es übersichtlicher wäre und die Abfragen einfacher zu erstellen wären wenn ich es in einer mache. Zumal die Abfragen auf jeder Seite gebraucht werden (Wenn die Übersichts- und die Bilderseite aufgerufen wird, werden die Kategorien aufgerufen, welche auch von der Rubrik abhängig sind, da es z.B. eine Kategorie Landschaft sowohl bei den Fotos als auch in der Malerei geben kann, welche aber unabhängig von einander sind. Dieses müssen dann ja den Bildern zugeordnet werden...also irgendwie gehört das ja alles zusammen... Besten dank für die Mühe... Lapje Geändert von Lapje (29.06.2011 um 10:35 Uhr).

29.06.2011, 11:14
Lapje Gast Beiträge: n/a	ok, was ich auf der schnelle lesen konnte sollte ich lieber für jede SPrache eine Tabelle machen, richtig? Was aber auch bedeuten würde, dass ich für jede Tabelle, in der verschiedene Sprachen sind, evt. 3 brauche....also bei bilder_uebersicht wären dass dann bilder_uebersicht_de ,bilder_uebersicht_pl und bilder_uebersicht für die restlichen Sachen...Oder ist das so gemeint, das zwei grundsätzliche Tabellen für alle Inhalte in den Sprachen angelegt werden, welche dann über IDs (z.B. sprache_pl_id mit der ID=1 ist für alle Texte, die in der polnischen Version in der Übersicht stehen, ID=2 für die deutschen Texte dort usw...) Ist das so gedacht? Ich dachte immer das es bei der Normalisierung darum geht, redundante Inhalte auszuschließen (z.B. das nirgendwo 5 mal der gleiche Ort auftaucht oder so). Das ist hier ja nicht gegeben, da in den Textinhalten ja immer verschiedene Dinge stehen und auch überall Text reingeschrieben wird (es wird also keine NULL-Felder geben). Zudem dachte ich dass es auch für die Abfrage einfacher und schneller ist, wenn alles aus einer Tabelle kommt... Ich bezweifle nicht was ihr sagt, nicht dass wir uns da falsch verstehen, es geht mir nur ums verstehen. Ich will ja nicht einfach irgendwas abschreiben, sondern ich will es auch anwenden können...

29.06.2011, 11:21
KarlEgon Erfahrener Benutzer Registriert seit: 24.10.2008 Beiträge: 298 PHP-Kenntnisse: Fortgeschritten	Nicht für jede Sprache eine eigene Tabelle, sondern eine Tabelle für Sprachen, welche du dann mit den Inhalten verknüpfen kannst

29.06.2011, 11:41
Lapje Gast Beiträge: n/a	ok, dann würde das dann so ausschauen: (als Beispiel) Tabelle texte bilder_uebersicht_ueberschrift_de bilder_uebersicht_ueberschrift_pl bilder_uebersicht_text_teaser_de bilder_uebersicht_text_teaser_pl bilder_text_de bilder_text_pl kategorie_name_de kategorie_name_pl navigation_name_de navigation_name_pl So? Aber da riskiere ich doch NULL -Einträge, oder? Ist dass denn dann ok? Denn nicht jedesmal wenn ich eine Kategorie anlege kommen auch Inhalte von Bildern dazu... Oder für die jeweils einzelnen Tabellen eine einzelne Tabelle für die Sprache? z.B. bilder_uebersicht_id bilder_uebersicht_datum bilder_uebersicht_vorschaubild bilder_uebersicht_status bilder_uebersicht_link bilder_uebersicht_zeitstempel und dann eine Tabelle mit den Inhalten: bilder_uebersicht_inhalt_ueberschrift_de bilder_uebersicht_inhalt_ueberschrift_pl bilder_uebersicht_inhalt_text_de bilder_uebersicht_inhalt_text_pl Oder so? Nur dadurch wird die Abfrage doch wesentlich aufwendiger, oder? Kann mir jetzt noch mal jemand erklären, wo genau die Normalisierung verletzt wird? Es entstehen doch keine redundanten Daten. Klar kann die Normalisierung immer weiter führen, aber würde hier nicht aufgrund der mehreren Tabellen nicht die performance leiden und würde das nicht übersichtlicher werden? Mal von der Fehleranfälligkeit abgesehen... Geändert von Lapje (29.06.2011 um 11:48 Uhr).

29.06.2011, 11:51
Maxefix Benutzer Registriert seit: 25.03.2011 Beiträge: 52 PHP-Kenntnisse: Fortgeschritten	Da es bei den zwei Sprachen höchstwahrscheinlich bleiben wird finde ich die jetzige Lösung schon OK. Es ist einfach und zielführend. Für jede Sprache eine extra Tabelle halte ich in dem Fall für nicht so gut. Die beiden Sprachversionen haben ja 1:1 den gleichen Inhalt, so wie ich das verstanden habe. Wenn du jetzt aber die Tabellen auseinander reißt kann es dir leicht passieren, dass die Datensätze unterschiedliche IDs haben, wodurch eine Zuordnung (Deutscher Datensatz <-> Polnischer Datensatz) erschwert wird. Außerdem musst du sämtliche Strukturänderungen doppelt vornehmen -> Wartungsunfreundlich. Eine Verknüpfungstabelle hat ja den Sinn eine m:n-Relation abzubilden. Das heißt jeder Eintrag kann mit beliebig vielen anderen Einträgen verknüpft sein. Durch die Abfrage der Verknüpfungstabelle willst du also rausfinden, mit welchen Datensätzen aus Tabelle B der Datensatz mit der ID 123 aus Tabelle A verknüpft ist. Beispiel: Code: mysql> select * from example_table where tabelle_a_id = 123; +--------------+--------------+ \| tabelle_a_id \| tabelle_b_id \| +--------------+--------------+ \| 123 \| 2 \| \| 123 \| 5 \| \| 123 \| 63 \| \| 123 \| 352 \| \| 123 \| 410 \| +--------------+--------------+ Bedeutet du weißt nicht wieviele Einträge zurück kommen. Der Datensatz kann ja nur mit einem anderen verknüpft sein, aber auch mit mehreren tausend. Du kannst jetzt natürlich noch eine Spalte für Tabelle C einfügen. Da die Verknüpfungen aber unabhängig von Tabelle B sind (der Datensatz kann 5 Datensätze aus B und 20 aus C zugewiesen haben), musst du die Verknüpfungen also eh in extra Zeilen speichern. Beispiel: Code: mysql> select * from example_table where tabelle_a_id = 123; +--------------+--------------+--------------+ \| tabelle_a_id \| tabelle_b_id \| tabelle_c_id \| +--------------+--------------+--------------+ \| 123 \| 2 \| NULL \| \| 123 \| 5 \| NULL \| \| 123 \| 63 \| NULL \| \| 123 \| 352 \| NULL \| \| 123 \| 410 \| NULL \| \| 123 \| NULL \| 34 \| \| 123 \| NULL \| 42 \| +--------------+--------------+--------------+ Du sparst dir also ansich nichts, aber es wird tendenziell eher unübersichtlicher. Darum macht es Sinn die Tabellen zu trennen. Ist vielleicht etwas umständlich erklärt, aber ich hoff du verstehst auf was ich hinaus will. Gruß, Max

29.06.2011, 12:54
Lapje Gast Beiträge: n/a	@Maxefix Das ist ja das was ich meinte... Die Inhalte werden immer gleich angeordnet, sprich: Zu jedem Eintrag gibt es einen deutschen und einen polnischen Teil. Zu jedem eintrag (z.B. unter Fotos) gibt es auch nur eine dazugehörige Bilderserie. Und auch jedes Foto kann/soll nur einer Serie zugeordnet werden, eine Serie enthält aber mehrere Bilder, was ja so erst mal kein Problem ist. Die einzigen Mehrfachverbindungen sind hier die Kategorien: Eine Bilderserie kann mehrere Kategorien beinhalten (z.B. Landschaft, Meer), eine Kategorie wird aber auch mehrere Bilderserien beinhalten. Genauso hängen aber auch die Rubriken (welche ich über die Navigation auflöse) und die Kategorien zusammen: Eine Rubrik kann mehrere Kategorien beinhalten, eine Kategorie soll aber nur einer Rubrik zugeordnet werden (Fotografien von Landschaften sind ja etwas anderes als Malereien von Landschaften). Trotzdem denke ich ist es einfacher (auch für die Abfrage) wenn alles in eienr Verbindungstabelle ist. Auch sehe ich es wie Du, dass durch mehrere Tabellen und veschiedene Abfragen die Gefahr grlßer ist, dass Abfragen sich verkomplizieren und sich Fehler einschleichten, die dann auch wieder schwerer zu erkennen sind. Nicht das wir uns falsch verstehen: Ich will allen anderen postern nicht widersprechen, das sind nur Gedanken die mir dabei kommen, da die Normalisierung ja redundante Daten verhindern soll, nur die sehe ich hier nicht (was nichts heißen soll)... Wenn aber jetzt z.B. in den Sprachen unterschiedliche Texte kommen würden (auch zu verschiedenen Zeitpunkten) und nicht alles in beiden Sprachen verfügbar ist, dann wäre die Lösung natürlich nicht optimal...