nicht angemeldet
mySQL - hirarchische Daten
suitHallo,
ich möchte mit einem SQL-Kommando alle Teile eines Produkts finden.
Beispiel:
PKW
- Getriebe
-
- (Baugruppen ...)
- Motor
-
- Anlasser
-
-
- Magnetschalter
-
-
-
-
- Schraube
-
-
-
-
-
- Mutter
-
-
-
-
- Rotor
-
-
-
- Stator
-
-
-
- Gehäuse
-
Bisher kenne ich nur den LEFT JOIN, der zu einer Baugruppe die Teile und die untergeordneten Baugruppen findet, aber nicht die untergeordneten Baugruppen weiter auflöst.
Wie könnte man sich diesem Thema nähern und was wäre die Bedingung in der Datenstruktur? Ich möchte auch den umgekehreten Weg gehen und einen Verwendungsnachweis für Teile haben. Also eine Liste, in welchen Baugruppen die Schraube 4711 vorkommt.
Gruß, Gast
-
Hi!
ich möchte mit einem SQL-Kommando alle Teile eines Produkts finden.
Wie könnte man sich diesem Thema nähern und was wäre die Bedingung in der Datenstruktur? Ich möchte auch den umgekehreten Weg gehen und einen Verwendungsnachweis für Teile haben. Also eine Liste, in welchen Baugruppen die Schraube 4711 vorkommt.Nested Sets wären eine Möglichkeit. Das Problem ist, wenn nur eine Beziehung zum Elternelement gepflegt ist, man sich durch jede Ebene einzeln hangeln muss. Mit Nested Sets kann man hingegen diverse Fragestellungen mit je einem Statement auf die Menge absetzen.
Lo!
-
Nested Sets wären eine Möglichkeit. Das Problem ist, wenn nur eine Beziehung zum Elternelement gepflegt ist, man sich durch jede Ebene einzeln hangeln muss. Mit Nested Sets kann man hingegen diverse Fragestellungen mit je einem Statement auf die Menge absetzen.
Man bekommt auch im Adjacency List Model alles mit einem Statement - es ist halt etwas unschön :)
Ein vergleich über die Möglichkeiten findet sich hier:
http://mikehillyer.com/articles/managing-hierarchical-data-in-mysql/Ein unbestrittener Vorteil von Nested Sets ist das einfache Lesen von Bäumen - der große Nachteil dabei ist aber, dass die Menschenlesbarkeit darunter leidet.
-
Hi!
Nested Sets wären eine Möglichkeit. Das Problem ist, wenn nur eine Beziehung zum Elternelement gepflegt ist, man sich durch jede Ebene einzeln hangeln muss. Mit Nested Sets kann man hingegen diverse Fragestellungen mit je einem Statement auf die Menge absetzen.
Man bekommt auch im Adjacency List Model alles mit einem Statement - es ist halt etwas unschön :)Unschön ist da wohl etwas untertrieben. Man muss zum Beispiel vorher wissen, wieviele Level nach unten und/oder nach oben man abzufragen gedenkt, um die richtige Anzahl Join notieren zu können.
Ein unbestrittener Vorteil von Nested Sets ist das einfache Lesen von Bäumen - der große Nachteil dabei ist aber, dass die Menschenlesbarkeit darunter leidet.
Inwiefern? Welche Lesbarkeit meinst du? Die Datensätze in der Tabelle betrachtend, das Statement, um sie abzufragen, ...?
Lo!
-
Inwiefern? Welche Lesbarkeit meinst du? Die Datensätze in der Tabelle betrachtend, das Statement, um sie abzufragen, ...?
Die Datensätze in der Tabelle - bei einer einfachen Elter-Kind-Beziehung kann man sofort ohne großartige Vorkenntnisse sagen welcher Datensatz wessen Kind ist oder umgekehrt und beim Einfügen kommt einfach eine Zeile dazu und beim entfernen einfach eine Zeile weg. Das kann jeder ohne nennenswerte Vorkennisse verstehen.
Bei Nested Sets hingegen ist die Sache signifikant komplizierter - ohne Administrationsoberfläche ist man hier schon ziemlich aufgeschmissen.
-
Tach!
Die Datensätze in der Tabelle - bei einer einfachen Elter-Kind-Beziehung kann man sofort ohne großartige Vorkenntnisse sagen welcher Datensatz wessen Kind ist oder umgekehrt und beim Einfügen kommt einfach eine Zeile dazu und beim entfernen einfach eine Zeile weg. Das kann jeder ohne nennenswerte Vorkennisse verstehen.
Bei Nested Sets hingegen ist die Sache signifikant komplizierter - ohne Administrationsoberfläche ist man hier schon ziemlich aufgeschmissen.Ja, unter Berücksichtigung, dass Logik nicht jedermans Sache ist, und es etwas mühsamer ist, zwei Zahlenwerte gegen zwei andere mit < und > zu vergleichen als einen Zahlenwert auf Gleichheit. Aber irgendeinen Tod muss man sterben. Dafür sind die Abfragemöglichkeiten deutlich umfangreicher. Die meiste Zeit wird man eh in irgendeiner Oberfläche verbringen und nicht in der Datenhaltung. Also ist das Verstehen und Implementieren ein mehr oder weniger einmaliger Akt.
dedlfix.
-
Aber irgendeinen Tod muss man sterben.
Das gilt in jeglicher hinsicht - kein System ist perfekt, aber igendwann muss man eine Entscheidung treffen und diese durchziehen, auch wenn es hinterher betrachtet die falsche war.
Dafür sind die Abfragemöglichkeiten deutlich umfangreicher. Die meiste Zeit wird man eh in irgendeiner Oberfläche verbringen und nicht in der Datenhaltung. Also ist das Verstehen und Implementieren ein mehr oder weniger einmaliger Akt.
Jein - oft ist es so, dass dann für Import- und Export-Routinen das Geld nicht mehr reiht, dann hat man ein mächtiges System und wenn man Daten rein oder rauskriegen will, hat man ein Problem :D
-
Tach!
Jein - oft ist es so, dass dann für Import- und Export-Routinen das Geld nicht mehr reiht, dann hat man ein mächtiges System und wenn man Daten rein oder rauskriegen will, hat man ein Problem :D
Theoretische Argumente kann ich auch bringen: Dann darf man Zeit und Geld eben nicht damit vergeuden, zunächst mit dem ungünstigen Datenformat anzufangen und anschließend nochmal alles umzuschreiben. Aber Import und Export ist doch - so es sich nicht um ein reines Backup-Dump und Restore handelt - etwas individuelles, was ohne Programmieraufwand kaum zu bewerkstelligen geht. Die grundlegenden Funktionen zum Einfügen von Elementen an vorgegebenen Positionen in den Baum sind sowieso vorhanden, die braucht nicht noch zu schreiben. Ich sehe da grad nichts, was nicht mit einer Schleife durch die Import-Daten und einem Funktionsaufruf zu erledigen wäre. Wo siehst du den entscheidenden Mehraufwand gegenüber dem Eltern-Kind-Modell?
dedlfix.
-
Ich sehe da grad nichts, was nicht mit einer Schleife durch die Import-Daten und einem Funktionsaufruf zu erledigen wäre. Wo siehst du den entscheidenden Mehraufwand gegenüber dem Eltern-Kind-Modell?
Beim Import von großen Datenmengen in flache Strukturen und umgekehrt - und das kommt nicht so selten vor, eben weil auch die Sekretärin vom Arzt die Eltern-Kind-Beziehung versteht, Nested Sets aber nicht.
Auch solche Dinge sollten dann in die Designentscheidung mit einfließen.
-
-
-
-
-
-
-