BurnerR
Bot #0384479
- Registriert
- 20 Juli 2013
- Beiträge
- 5.505
Ich sitze hier gerade an einer Datenbank und bin mir etwas unsicher, wie ich sie am besten designe.
[Weiter unten sind ER-Diagramme]
Die zentrale Entität sind die Objekte.
Ein Objekt hat (im Sinne einer 1:n Beziehung) jeweils ein material, ein material specified, ein kind of object und ein kind of object specified
Letztere sind hierarchisch organisiert, d.h. jeweils 1:n
material --> material specified --> kind of object --> kind of object specified
Dazu kommen mehrere Eigenschaften die decoration, color, production, die jeweils zu kind of object specified gehören.
Das ganze sieht dann so aus:
Frage: Kann ich das guten Gewissens so machen? Macht die Zirkularität nicht Probleme?
---
Weiteres Problem
productions, decorations, colors, etc. da hat sich jetzt gezeigt, dass es relativ viel Überlappung gibt. Bei kind of object specified auch.
D.h. bei kind of object specified gibt es z.B. 10 mal "big vessel" für verschiedene kind of objects.
Bei colors (und dem Rest auch) das selbe. Da gibt es z.B. 10 mal "rot" für die verschiedenen kind of objects specifieds. Weil nunmal ein "big vessel" rot sein kann und ein "small vessel΅ auch. Eine "glass door" kann aber z.B. nicht rot sein.
EIne Variante wäre z.B. 1:n ganz normal bis kind of object specified zu machen und für den Rest eine Materialized Path-artige Struktur herzunehmen. Jede color, decoration, etc. hätte dann mehrere (1:n) paths:
Erläuterung zum paths-table:
Könnte ich dann evtl. auch direkt ebenso für kind of object specifieds einführen?
Deutlich einfacher wäre es natürlich, die Doppelungen bei kind of object specified hinzunehmen und diese in eine n Beziehung mit production, decoration etc. zu setzen. Allerdings gibt es jetzt aktuell knapp 1000 Einträge in kind of object specified und das ist ziemlich unübersichtlich das zu verwalten, gerade mit den ganzen Doppelungen (ich denke mal so 80% Überschneidung).
Die Variante mit den materialzed paths klingt irgendwie verlockend. Könnte man auch für die Objekte einführen.
Bin mir aber nicht sicher was Aufwand und Pitfalls angeht.
Weitere alternative wäre eine fertiges Funktionalität herzunehmen: Ancestry for Rails.
Problem dabei ist, dass ich dann die "Typsicherheit" verliere, weil materialzed path im eigentlichen Sinne nur "Nodes" ohne besonderen Typ kennt.
[Weiter unten sind ER-Diagramme]
Die zentrale Entität sind die Objekte.
Ein Objekt hat (im Sinne einer 1:n Beziehung) jeweils ein material, ein material specified, ein kind of object und ein kind of object specified
Letztere sind hierarchisch organisiert, d.h. jeweils 1:n
material --> material specified --> kind of object --> kind of object specified
Dazu kommen mehrere Eigenschaften die decoration, color, production, die jeweils zu kind of object specified gehören.
Das ganze sieht dann so aus:
Frage: Kann ich das guten Gewissens so machen? Macht die Zirkularität nicht Probleme?
---
Weiteres Problem
productions, decorations, colors, etc. da hat sich jetzt gezeigt, dass es relativ viel Überlappung gibt. Bei kind of object specified auch.
D.h. bei kind of object specified gibt es z.B. 10 mal "big vessel" für verschiedene kind of objects.
Bei colors (und dem Rest auch) das selbe. Da gibt es z.B. 10 mal "rot" für die verschiedenen kind of objects specifieds. Weil nunmal ein "big vessel" rot sein kann und ein "small vessel΅ auch. Eine "glass door" kann aber z.B. nicht rot sein.
EIne Variante wäre z.B. 1:n ganz normal bis kind of object specified zu machen und für den Rest eine Materialized Path-artige Struktur herzunehmen. Jede color, decoration, etc. hätte dann mehrere (1:n) paths:
Erläuterung zum paths-table:
Der table hat (neben einem PK) einen varchar, wo der pfad abgespeichert wird in der Form:
"material_id / material_specified_id / kind_of_object_id / kind_of_object_specified_id"
also z.B.:
"3/1/5/6"
"material_id / material_specified_id / kind_of_object_id / kind_of_object_specified_id"
also z.B.:
"3/1/5/6"
Könnte ich dann evtl. auch direkt ebenso für kind of object specifieds einführen?
Deutlich einfacher wäre es natürlich, die Doppelungen bei kind of object specified hinzunehmen und diese in eine n Beziehung mit production, decoration etc. zu setzen. Allerdings gibt es jetzt aktuell knapp 1000 Einträge in kind of object specified und das ist ziemlich unübersichtlich das zu verwalten, gerade mit den ganzen Doppelungen (ich denke mal so 80% Überschneidung).
Die Variante mit den materialzed paths klingt irgendwie verlockend. Könnte man auch für die Objekte einführen.
Bin mir aber nicht sicher was Aufwand und Pitfalls angeht.
Weitere alternative wäre eine fertiges Funktionalität herzunehmen: Ancestry for Rails.
Problem dabei ist, dass ich dann die "Typsicherheit" verliere, weil materialzed path im eigentlichen Sinne nur "Nodes" ohne besonderen Typ kennt.
Zuletzt bearbeitet: