Hierarchie in Datenbank

[soulspirit]

Hallo,

ich bin dabei eine universelle baumstruktur auf die datenbank abzubilden. das ganze dient dazu, daten in der datenbank später in einem userinterface hierarchisch darstellen zu können.

dabei ist die datenbankseite das kleinere problem, ich hab da schon eine lösung die meinen bedürfnissen entspricht:

tables:
TreeIndex -> eine art inhaltsverzeichnis meiner trees
node, node-relations -> knoten im baum. zwischen den knoten bestehen n:m rellationen.
node-type -> knotentyp könnte z.b. land, stadt oder bundesland sein
data-item, data-item-type -> jeder knoten kann daten enthalten wie z.b. die summe der einwohner


ich habe auch schon einen service in hibernate geschrieben, leider ist das ergebnis eher unbefriedigend. der service schafft es "nur" beim übergeben eines knotens, diesen und alle erreichbaren knoten persistent in der datenbank abzulegen. dazu natürlich auch alle data-items usw.. außerdem ein etwas umständliches navigieren durch einen baum. leider schaff ich es nicht eine vernünftige lösung zum verändern eines bestehenden trees zu implementieren. das ganze schaut jetzt schon ziemlich hässlich aus..


vielleicht hätte jemand ein paar links zu artikeln über dieses thema oder buchempfehlungen?

unser projekt baut auf spring und hibernate auf falls das eine hilfe ist.

bin für jede hilfe dankbar!

 

[maki]

Mein Tipp: Kein Rekursives Netzwerk aufbauen, macht das ganze unötig komplex, Trees reichen imho meist aus.
Konkret: 1:N Beziehungen von Knoten anstatt m:n

Dazu reicht es, ein Feld in der NODE Tabelle zu haben, welches zB PARENT_ID heisst.

 

[soulspirit]

naja ich würd nicht eine m:n beziehung implementieren wenn es nicht unbedingt nötig wäre - das in hibernate ist ohnehin kein zuckerschlecken leider ist es unbedingt notwendig und hat am ende sogar seine vorteile.

 

[maki]

Rekursiv m:n ist nie ein Zuckerschlecken, ob mit SQL oder Hibernate, darüber hinaus nicht nötig wenn man die Sache richtig aufzieht

Inhalt von Struktur trennen ist eine gute Sache.

Sieh es mal so:
Nodes haben nur Strukturelle Daten, der Inhalt wird in einem eigenen Objekt gespeichert.
Damit ist jeder Node eindeutig, weil er nur ein einziges mal vorkommen kann, aber das Datenobjekt kann von beliebig vielen Knoten referenziert werden.
Voila! Keine M:N Kiste mehr.

 

[soulspirit]

ich glaub ich hab da ein bisschen zu kurz gedacht. bis jetzt hab ichs so:

treenodetype ist der typ eines knotens - z.b. der typ postleitzahl
treenode enthält dann die daten zum typ - z.b. die postleitzahl D-12345
dataitem enthält dann berechnete daten für jeden knoten - z.b. summer der einwohner pro postleitzahl (vereinfacht gesagt *g*)


was du meinst ist wenn ich dich richtig verstehe, dass ich noch eine klasse einführen sollte:
nennen wir sie mal treenodedata - in der ich dann in diesem fall z.b. die postleitzahl speichere?

und in treenode steht gar nichts mehr außer eine id und die foreign-keys auf treenodetype, dataitem und treenodedata?

hmm ok ich werd mal darüber nachdenken. vor allem ist mir nicht ganz klar ob mir das dabei hilft die braumstruktur leichter managen zu können ???:L .

ich wär immer noch sehr dankbar wenn jemand lektüre zum thema persistente trees oder ähnliches anzubieten hätte entweder hab ich die falschen suchbegriffe oder google gibt einfach nichts her

 

[maki]

und in treenode steht gar nichts mehr außer eine id und die foreign-keys auf treenodetype, dataitem und treenodedata?

Ja, so ähnlich war es gedacht!

Struktur (Tree) vom Inhalt trennen (Postleitzahl).

Am besten noch ein paar schöne Abstraktionen der Domäne als Klassen formulieren (Adresse, etc. pp.).

Wenn du Hibernate einsetzt, solltest du deine Node Klassen nach dem Entwurfsmuster "Kompositium" (bzw. Composite Pattern <- google) aufbauen.

 

[soulspirit]

Wenn du Hibernate einsetzt, solltest du deine Node Klassen nach dem Entwurfsmuster "Kompositium" (bzw. Composite Pattern <- google) aufbauen.

welche vorteile hätte ich dadurch?

ich müsste dann beim traversieren jedesmal eine abfrage "node instanceof leavenode" + entsprechenden cast machen um eine stufe weiter zu traversieren. wäre es da nicht einfacher, einen getter zu schreiben:

public boolean isLeave() {
  return this.children.size() == 0;
}

oder überseh ich da was?

//edit:
vielleicht ein kurzes beispiel was du genau im composite-pattern aufbauen willst. ich steh grad auf der leitung ???:L

 

[maki]

Wozu instanceof bzw. einen Cast?
Es sollten doch alle nodes dasselbe Interface implementieren.
Du kannst auch ein Composite aufbauen, indem du nur eine Art von Nodes anbietest