Designfrage zu Rows die sich auf einen Datensatz derselben Tabelle beziehen

[mfernau]

Hallo!

Ich weiss gar nicht wie ich den Titel besser beschreiben könnte. Es geht mir Prinzipiell um die Frage, wie man bei einem Tabellenaufbau Kontrukte Abbildet, die quasi einen Datensatz derselben Tabelle referenzieren. Als Konkretes Beispiel habe ich gerade die "istFilialeVon" Beziehung zu lösen.

Also ich habe eine Tabelle 'customer', welche alle Kunden von mir beinhaltet. Es kommen auch Kunden vor, die mehrere Filialen besitzen. Die Filialen bekommen von mir ebenfalls einen ganz normalen Kunden-Stammsatz mit einer eigenen Kundennummer verpasst. Nun möchte ich die Information, dass es sich um eine Filiale handelt, nicht verlieren und habe spontan zwei Möglichkeiten dies abzubilden:

Möglichkeit 1: Ich füge die Spalte 'isAffilateOf' hinzu, welche einfach die konkrete Kundennummer des Hauptsitzes referenziert.
Möglichkeit 2: Ich erstelle eine Referenzierungstabelle der Form (custimerId, affilateCustomerId) die also eine Auflistung aller Filialen zu einem Hauptsitz enthält. Oder eben keine, wenn es keine Filialen gibt.

Beides geht - meine Frage ist nur was davon gebräuchlicher ist, bzw. was für Vor-/Nachteile ergeben sich aus den einzelnen Vorgehensweisen? Da ich mich schon mehrfach mit dieser Frage konfrontiert habe wollte ich das endlich mal lösen

Besten Dank und Grüße
Martin

 

[vanny]

Ich würde mir an deiner Stelle immer die Frage nach Redundanz stellen.
Wenn ich also FilialeX mehr als einmal zuordne, dann ist eine n : m beziehung sinnvoll.
Wenn jede Filiale nur genau einen Kunden hat ist 1 : n besser.

Gruß Vanny

 

[mfernau]

Hm ja stimmt. Mit einer extra Tabelle stellt man ja eine m:n Beziehung dar. Das wäre hier ja nicht nötig.
Bei diesem praktischem Beispiel ist eine Filiale natürlich immer nur einem Hauptbetrieb zugeordnet. Also wäre hier die Fremdschlüsselzuordnung innerhalb derselben Tabelle wohl völlig normal.

 

[vanny]

... Fremdschlüsselzuordnung innerhalb derselben Tabelle ...

öhm*hust*, das klingt komisch.
1:n = 2 Tabellen
n:m = 3 Tabellen.

ergo 1:n:
Bei dir eine Tabelle Hauptbetrieb mit zBsp. id als Primärschlüssel und einmal Filiale und dort dann id_hauptbetrieb als Fremdschlüssel.

 

[mfernau]

öhm*hust*, das klingt komisch.
1:n = 2 Tabellen
n:m = 3 Tabellen.

ergo 1:n:
Bei dir eine Tabelle Hauptbetrieb mit zBsp. id als Primärschlüssel und einmal Filiale und dort dann id_hauptbetrieb als Fremdschlüssel.

Ne, vermutlich missverstanden. Pass auf:

Tabelle "Kunde":
- id (kdnr)
- name
- adresse
- plz
- ort
- telefon
- etc...

So sieht sie mal vereinfacht aus. Also ein Kunde "Müller GmbH" aus Musterstadt hat z.b. die id (kdnr) 12345. Jetzt hat der Müller noch eine Filiale die ebenfalls bei uns Kunde ist. Das wäre dann "Müller GmbH" aus Großkleinstadt und hat dann z.b. die id 12789. Beides sind bei uns in erster Linie ganz normale getrennte Kundensätze. Jetzt möchte ich in meiner Verwaltungssoftware aber den Zusammenhang, dass die kdnr 12789 eine Filiale von 12345 ist, informativ anzeigen können.

Jetzt könnte ich die Tabelle "Kunde" aufbohren und um die Spalte 'hauptbetriebId' erweitern. Diese Spalte ist entweder NULL (im Fall von 12345) oder enthält '12345' im Fall von 12789.
Die andere Variante wäre eine zweite Tabelle die nichts weiter tut als diesen Zusammenhang darzustellen:

Tabelle 'Filiale' die nur zwei Spalten enthält:
- hauptbetriebId
- filialeId

Meine Frage zielt jetzt darauf ab, ob eher die erste Variante praxisnah ist, oder eher die zweite.
Beide haben meiner Meinung nach vor und Nachteile.
Der gefühlte Nachteil der ersten Variante ist der, dass der Inhalt der Spalte 'hauptbetriebId' nicht immer gesetzt ist - also NULL sein kann. Das ist halt etwas ungewöhnlich. Außerdem gefällt mir die trennung dieser Information in eine getrennte Tabelle aus kosmetischen Gründen, da diese Filialinformation nicht direkt etwas mit dem Kundenstammsatz zu tun hat.
Die zweite Variante wiederum hätte den Nachteil, dass damit auch Beziehungen darstellbar wären, die vielleicht nicht stimmen: Ein Betrieb könnte eine Filiale von mehreren Betrieben sein (dem könnte ich allerdings abhilfe schaffen, indem ich filialeId unique mache). Außerdem würde es zu erhöter Unübersichtlichkeit kommen, wenn man diesen Ansatz agressiv auch für andere solche Situationen einsetzen würde (viele Joins im Select, viele kleine Tabellen, etc).

Womit ich wieder am Anfang stehe
Gedanklich verfolge ich daher dann eher die erste Variante

 

[vanny]

Ok, da haben wir uns tatsächlich missverstanden^^

in diesem Fall kann ich auch nicht zwischen richtig oder falsch entscheiden und finde ne zusätzliche Tabelle besser, weil
1. eine saubere Trennung/Zuordnung erfolgt und
2. wenn auch unwahrscheinlich, kannst du den wechsel des Hauptbetriebes einer Filiale erfassen und bist somit flexibler.

Gruß Vanny

 

[mfernau]

alles klar, dann wird das jetzt über eine zweite Tabelle gelöst.
Ich dachte halt nur es gäbe da eine Art Design-Pattern oder Konvention die soetwas "vorschreibt". Da ich in DB-Programmierung nich so tief drin stecke wollte ich mal gefragt haben

Danke und Grüße
Martin

 

[fastjack]

öhm*hust*, das klingt komisch.

Warum? Das ist einfach eine Referenz auf sich selbst.