MySQL - Design Frage

[Thomas]

Hallo zusammen,

mal eine kurze Frage die ich gerade im Kopf habe:

• Ich habe hier mehrere Buchungen
• Jede Buchung hat eine Buchungsart

Warum, Wieso ist in diesem Beispiel nicht wichtig.

Normalerweise würde ich ja sagen:

• Eine Buchung hat eine Buchungsart
• Eine Buchungsart hat 1 oder n Buchungen

also wäre das eine 1 zu n Beziehung.

Tabelle: Buchung
Felder: ID, Buchungsartikel, Anzahl, BuchungsartID

Tabelle: Buchungsart
Felder: ID, Name, usw...

Verknüpfung über BuchungsartID und ID der Tabelle Buchungsart.

Aber ich könnte doch auch eine Verknüpfungstabelle benutzen, auch wenn es keine n zu n Beziehung ist!?

Tabelle: Buchung
Felder: ID, Buchungsartikel, Anzahl

Tabelle: Buchungsart
Felder: ID, Name, usw...

Tabelle: Buchung_Buchungsart
Felder: BuchungID, BuchungsartID

So wäre jede Tabelle für sich und hätte keine zig ID Felder in sich.
Und das schöne wäre wenn ich das immer so machen würde, das ich bei Dingen die neu dazukommen nicht mehr die bestehenden Tabellen ändern müsste.

Angenommen ich will jetzt noch den Benutzer der Buchung, dann reicht eine neue Tabelle Buchung_Benutzer und die Tabelle Benutzer. Die Tabelle Buchung kann ich unberührt lassen.

Liege ich damit falsch?
Ist das doch nicht so toll wie ich denke?

Grüße
Thomas

[Felix Riesterer]

Lieber Thomas,

nach meinem noch recht jungen Verständnis der Materie stellen sich hier zwei Abwägungen.

1.) Wie umständlich sollen die Anfragen an den DB-Server werden (wieviele Joins), um an Deine gewünschten Daten zu kommen?
2.) Wie frei erweiterbar soll Deine DB aufgebaut werden?

Den Kompromiss musst Du finden.

In Deinem konkreten Beispiel tendiere ich sehr stark zu Deiner 1:n-Lösung, da man mit einem relativ einfachen Join die Buchungsart zu der Buchung ermitteln kann. Bei einer Lösung mit drei verschiedenen Tabellen wird das schnell unübersichtlich.

Wegen der "Erweiterbarkeit": Was spricht denn gegen eine neue Spalte in einer bereits vorhandenen Tabelle, anstatt eine neue Tabelle anzulegen? in beiden Fällen wirst Du Datenbestände haben, die diese neue "Eigenschaft" nicht haben, sei es in der neuen (leeren) Spalte, oder in der neuen Tabelle (in der sie nicht aufgeführt werden)!

Liebe Grüße,

Felix Riesterer.

[Thomas]

Hallo Felix,

1.) Wie umständlich sollen die Anfragen an den DB-Server werden (wieviele Joins), um an Deine gewünschten Daten zu kommen?
2.) Wie frei erweiterbar soll Deine DB aufgebaut werden?

Den Kompromiss musst Du finden.

Also weg vom Schwarz-Weiß denken und was gutes Graues finden.

Bei einer Lösung mit drei verschiedenen Tabellen wird das schnell unübersichtlich.

Das stimmt allerdings. Das ist ein echtes Problem. Ging mir kürzlich erst bei einem Projekt so das sehr "erweiterbar" aufgebaut war. Aber ich habs irgendwie verdrängt.

Wegen der "Erweiterbarkeit": Was spricht denn gegen eine neue Spalte in einer bereits vorhandenen Tabelle, anstatt eine neue Tabelle anzulegen?

Das ich bei zu vielen Beziehungen irgendwann, einfach ein Haufen Spalten habe, die nichts weiter als eine ID beinhalten.

Jetzt kam mir gerade noch, vielleicht könnte man auch eine neue Tabelle anlegen die alle Beziehungen der Tabelle beinhaltet.

Soll heißen:

Tabelle: Buchung
Felder: ID, Artikel, usw..

Tabelle: Buchung_Beziehung
Felder: BuchungID, BuchungsartID, BenutzerID, LagerID, usw..

Das wäre doch eigentlich auch eine schicke Möglichkeit den ID Inhalt zu verbannen?

Liebe Grüße,
Felix Riesterer.

Grüße
Thomas

[Felix Riesterer]

Lieber Thomas,

Jetzt kam mir gerade noch, vielleicht könnte man auch eine neue Tabelle anlegen die alle Beziehungen der Tabelle beinhaltet.

eine Meta-Tabelle. Fein. <sarcasm>Warum legst Du dann aber nicht für jede Buchung eine neue Tabelle an?</sarcasm>

In dieser Sache empfinde ich sehr stark wie Dennis.

Liebe Grüße,

Felix Riesterer.

[Der-Dennis]

Hey Thomas,

Aber ich könnte doch auch eine Verknüpfungstabelle benutzen, auch wenn es keine n zu n Beziehung ist!?

das kannst Du grundsätzlich machen.

So wäre jede Tabelle für sich und hätte keine zig ID Felder in sich.
Und das schöne wäre wenn ich das immer so machen würde, das ich bei Dingen die neu dazukommen nicht mehr die bestehenden Tabellen ändern müsste.

Angenommen ich will jetzt noch den Benutzer der Buchung, dann reicht eine neue Tabelle Buchung_Benutzer und die Tabelle Benutzer. Die Tabelle Buchung kann ich unberührt lassen.

Auch das stimmt grundsätzlich. Ich denke allerdings, dass der Aufwand eine neue Tabelle zu erstellen größer ist als ein neues Feld in einer bereits bestehenden Tabelle anzulegen.

Liege ich damit falsch?
Ist das doch nicht so toll wie ich denke?

Auch hierbei ich nur für mich sprechen: Ich nutze solch eine Verknüpfungstabelle nur bei einer n-n Beziehung. Benutzt man sie auch bei einer 1-n Beziehung, bräuchtest Du bei der Abfrage auf jeden Fall einen Join mehr, den ich mir gerne spare. Auch bei einem neuen Eintrag (einer neuen Buchung) müsste ich immer gleich mindestens zwei Tabellen ändern.

Gruß, Dennis

[Encoder]

So wäre jede Tabelle für sich und hätte keine zig ID Felder in sich.

Dafür hast du eine Tabelle mehr die nur IDs enthält. Ist das etwa schön?

Du hast dem Eindruck nach eine wirkliche 1:n Beziehung in dem Sinn dass eine Buchung genau eine Buchungsart hat. Dann gehört die da auch mit rein. Alles andere kann man zwar schon machen, ist aber nicht "schön" oder empfehlenswert.

[Ilja]

moin,

• Eine Buchung hat eine Buchungsart
• Eine Buchungsart hat 1 oder n Buchungen
  also wäre das eine 1 zu n Beziehung.

nicht zwangsläufig. die frage ist, ob buchungsart ein attribut des entitätstyp buchung ist oder aben ein attribut des entitätstyp buchungsart und die beiden in beziehung miteinander stehen. das sind zwei verschiedene dinge.

Ilja

[Thomas]

Hi Ilja,

nicht zwangsläufig. die frage ist, ob buchungsart ein attribut des entitätstyp buchung ist oder ...

Sorry ich kann dir hier nicht so ganz folgen. Wie meinst du das?

Grüße
Thomas

[Ilja]

moin,

Sorry ich kann dir hier nicht so ganz folgen. Wie meinst du das?

du musst nicht zwwangsläufig eine 1:n beziehung haben, sondern es ist auch möglich, alles in einer tabelle abzubilden, nämlich die buchungsart direkt im klartext in der buchung steht. dann wäre buchungsart ein attribut des entitätstyp buchung. das hängt immer von den jeweligen gegenheiten ab und wie du die abhängikeiten modellieren willst.

Ilja

[Thomas]

Sorry ich kann dir hier nicht so ganz folgen. Wie meinst du das?

du musst nicht zwwangsläufig eine 1:n beziehung haben, sondern ...

Ah, ok. Jetzt komm ich mit :) Vielen Dank für deine Erklärung.

Grüße Thomas

[MudGuard]

Hi,

Aber ich könnte doch auch eine Verknüpfungstabelle benutzen, auch wenn es keine n zu n Beziehung ist!?

Tabelle: Buchung
Felder: ID, Buchungsartikel, Anzahl

Tabelle: Buchungsart
Felder: ID, Name, usw...

Tabelle: Buchung_Buchungsart
Felder: BuchungID, BuchungsartID

Mit der Gefahr, daß einer Buchung dann auch mehrere Buchungsarten zugeordnet werden können.
Das könnte man zwar noch mit einem Unique-Constraint auf der BuchungID der Buchung_Buchungsart-Tabelle verhindern.

Aber es besteht auch die Gefahr, daß einer Buchung KEINE Buchungsart zugeordnet wird.
Bei einer Spalte in der Tabelle Buchung könnte man das per "NOT NULL" verhindern, aber bei Deinem Konstrukt?

So wäre jede Tabelle für sich und hätte keine zig ID Felder in sich.

Dafür gibt es dann zig Verknüpfungstabellen.

Und das schöne wäre wenn ich das immer so machen würde, das ich bei Dingen die neu dazukommen nicht mehr die bestehenden Tabellen ändern müsste.

Dafür mußt Du eine neue Verknüpfungstabelle einfügen.
Und was ist so tragisch daran, die bestehende Tabelle zu ändern?

Außerdem: wo vorher 1 Join gereicht hat, um zur Buchung den Namen der Buchungsart zu bekommen, brauchst Du jetzt 2 Joins.
Bei zig ID-Feldern hast Du dann statt zig joins zigzig joins, nämlich doppelt so viele.

cu,
Andreas