"Klassenhierarchie" abbilden

[StefanKöln]

Hallo,

ich habe folgendes Problem. Ich möchte Daten zu Handelsrouten speichern. Eine Handelsroute besteht dabei aus einem Startpunkt und einem Endpunkt. Nun können diese Punkte aber unterschiedlichen Typs sein: Häfen und "nicht Häfen".

Ich habe vor die Tabellen wie folgt zu definieren:

Route: ID, name, startStandort_FK, endStartpunkt_FK
Standort: ID, name
Hafen: ID, standort_FK, [sonstige Attribute]
"nichtHafen": ID, standort_FK, [sonstige Attribute]

Damit sind quasi Häfen und "nicht Häfen" eine Spezialisierung von Standort. Haltet Ihr diese Vorgehensweise für eine gute Idee?

Vielen Dank
Stefan

[Novi]

Hi,

wenn ich deine Tabellen richtig verstehe könntest du dir eine Id sparen:

Route: ID, name, startStandortId, endStartpunkt_Id
Standort: Id, name
Hafen: Id, [sonstige Attribute]
"nichtHafen": Id, [sonstige Attribute]

Damit hättest du quasi Lücken bei den Id's in den Tabellen Hafen und "nichtHafen", aber das dürfte egal sein. Dafür dürften sich die Daten einfacher handhaben lassen, da du so weniger Id's hast.

[StefanKöln]

Ich denke das ist es noch nicht ganz. Ich versuche mich nochmal an der Problembeschreibung. Die war wohl eher undeutlich.

Ich habe Häfen:
Hafen: ID, name, maxUmsatzProTag, maxSchiffsgroeße

und LandTransportPunkte:
LandTransportPunkt: ID, name, zollProME, waehrung

Diese beiden möchte ich in Routen aufnehmen können:
Route: ID, name, startPunktID, endPunktID

Wenn ich nun eine Route mit Start- und Endpunkt habe muss ich wissen, ob es sich um Häfen oder LandTransportPunkte handelt, um eine entsprechende Verknüpfung herstellen zu können...

Vielleicht ist auch der ganze Ansatz falsch. Irgendwie kommt mir das nur seltsam vor...

[Novi]

Hi,

die entsprechende Verknüpfung erhältst du durch die Prüfung, ob ein Datensatz z.B. mit der startPunktId in der Tabelle Hafen oder in der Tabelle LandTransportPunkt vorkommt. Dadurch musst du nicht zusätzlich die Art des Standortes speichern.

Route
 Id |  name | startPunktID | endPunktID
----|-------|--------------|-----------
  1 | Bla1  |      1       |     2
  2 | Bla2  |      1       |     3
  3 | Bla3  |      3       |     2
  4 | Bla4  |      4       |     2
  5 | Bla5  |      1       |     4

Hafen
 Id | name | maxUmsatzProTag | maxSchiffsgroeße
----|------|-----------------|-----------------
  1 | haf1 |      432        |    86568565
  4 | haf2 |      454        |    83242315

LandTransportPunkt
 Id | name | zollProME | waehrung
----|------|-----------|---------
  2 | lan1 |    431    |    1
  3 | lan2 |    454    |    2


Route "Bla1"(1) geht von Hafen "haf1"(1) zum LandTransportpunkt "lan1"(2).
Route "Bla2"(2) geht von Hafen "haf1"(1) zum LandTransportpunkt "lan2"(3).
Route "Bla3"(3) geht von Hafen "lan2"(3) zum LandTransportpunkt "lan1"(2).
Route "Bla4"(4) geht von Hafen "haf2"(4) zum LandTransportpunkt "lan1"(2).
Route "Bla5"(5) geht von Hafen "haf1"(1) zum LandTransportpunkt "haf2"(4).

[fanderlf]

Der obige Ansatz hat allerdings das Problem, dass man keine FKs anlegen kann.

Wenn Du alles in eine Tabelle packst, dann kannst Du FKs anlegen, allerdings hast Du dann auch teilweise Spalten in denen je nach Typ keine Werte stehen.

Im Prinzip gibt es 3 Möglichkeiten Klassenhierarchien in einer DB abzubilden:
1. Table per class hierarchy - Eine Tabelle für eine Klassenhierarchie - Unterscheidung der einzelnen Klassen durch eine extra Spalte
2. Table per Class - eine Tabelle für jede konkrete Klasse
3. Table per Subclass - eine Tabelle für jede Unterklasse, die gemeinsamen Daten werden in einer entsprechenden Tabelle verwaltet

kann man sehr schön in der NHibernate Referenz nachlesen unter Punkt 8 (Inheritance Mapping).

[Novi]

Der obige Ansatz hat allerdings das Problem, dass man keine FKs anlegen kann.

Hi,

könnte man nicht Fremdschlüssel anlegen, wenn man noch zusätzlich eine Tabelle Standorte hätte?

Also ungefähr so:

Route
 Id |  name | startPunktID | endPunktID
----|-------|--------------|-----------
  1 | Bla1  |      1       |     2
  2 | Bla2  |      1       |     3
  3 | Bla3  |      3       |     2
  4 | Bla4  |      4       |     2
  5 | Bla5  |      1       |     4

Standort
 Id | name
----|-----
  1 | haf1
  2 | lan1
  3 | lan2
  4 | haf2

Hafen
 Id | maxUmsatzProTag | maxSchiffsgroeße
----|-----------------|-----------------
  1 |      432        |    86568565
  4 |      454        |    83242315

LandTransportPunkt
 Id | zollProME | waehrung
----|-----------|---------
  2 |    431    |    1
  3 |    454    |    2

Gut das würde dann wohl deinem Punkt 3 ("Table per Subclass") entsprechen.

[fanderlf]

Jup genau wobei ich dann als PK nicht in beiden Fällen denselben verwenden würde, sondern wieder separate.
Hafen und Landtransport bekämen unabhängige PKs und würde jeweils einen FK auf den Eintrag in der Standort Tabelle haben.
Mir behagt es irgendwie nicht ein und denselben PK an 2 Stellen in der DB zu verwenden.

[Novi]

Jup genau wobei ich dann als PK nicht in beiden Fällen denselben verwenden würde, sondern wieder separate.
Hafen und Landtransport bekämen unabhängige PKs und würde jeweils einen FK auf den Eintrag in der Standort Tabelle haben.

Gut dadurch würden sie ja nur zusätzliche ID's kriegen. Schaden kann dass auf jeden Fall nicht.

Mir behagt es irgendwie nicht ein und denselben PK an 2 Stellen in der DB zu verwenden.

Ja, ganz schön fand ich den Gedanken auch nicht. Ich glaube dein Vorschlag ist sehr viel sauberer. Ich hab das mal wieder versucht darzustellen:

Route
 id |  name | startPunktID | endPunktID
----|-------|--------------|-----------
  1 | Bla1  |      1       |     2
  2 | Bla2  |      1       |     3
  3 | Bla3  |      3       |     2
  4 | Bla4  |      4       |     2
  5 | Bla5  |      1       |     4

Standort
 id | name
----|-----
  1 | haf1
  2 | lan1
  3 | lan2
  4 | haf2

Hafen
 id | standordId | maxUmsatzProTag | maxSchiffsgroeße
----|------------|-----------------|-----------------
  1 |     1      |      432        |    86568565
  2 |     4      |      454        |    83242315

LandTransportPunkt
 id | standordId | zollProME | waehrung
----|------------|-----------|---------
  1 |     2      |    431    |    1
  2 |     3      |    454    |    2

Hmm,

mir fällt gerade auf, das wir so wieder bei der Lösung sind, die Stefan von Anfang gehabt hatte. Diese Idee war also wohl ganz gut. Aber so sind wir die anderen Möglichkeiten auch mal durchgegangen.

[fanderlf]

Ja so hab ich mir das vorgestellt, aber es kommt wie gesagt immer auf den jeweiligen Fall an. Allerdings hat man eben mit dieser Lösung viele JOINS zu machen. In einer Tabelle muss man weniger JOINs machen braucht aber dafür Speicherplatz um die leeren Felder abzulegen. Hat beides seine PROs und CONTRAs.
Ich tendiere immer zu der Lösung mit weniger JOINs, weil diese gerade bei großen Tabellen doch recht die performance drücken. Allerdings werden wohl die Standorte Tabellen selten wirklich groß werden.

[StefanKöln]

Gut, danke für die rege Diskussion. Scheinbar gibt es doch nicht "die" Lösung für diese Fragestellung. Aber so bin ich beruhigt, dass mein Vorgehen nicht so ganz falsch sein kann.

Werde mich dann wohl für die von mir eingangs vorgeschlagene Lösung mit den vielen Joints entscheiden. Ich denke das ist für mich leichter vorstellbar und damit weniger fehleranfällig. Da darf ruhig die Performance ein wenig leiden =)

Danke nochmal
Stefan

[fanderlf]

Also die schönste Lösung ist mit Sicherheit die von Dir (StefanKöln). Zumindest vom Design her.

Aber wenn ich im Vorfeld schon weiss, dass ich den Tabellen mehrere 10000 Datensätze stehen werden, dann werden JOINs sehr schnell sehr sehr groß. Dann sollte man zugunsten der Performance etwas über das Design hinweg sehen