MySQL 5.0 alle Kinder auflisten

[Melanie G.]

Hallo!

ich habe eine Tabelle. Zwei Spalten davon sind id und pid.

+----+-----+---
| id | pid |
+----+-----+---
| 1  |     |
+----+-----+---
| 2  | 1   |
+----+-----+---
| 3  |     |
+----+-----+---
| 4  | 3   |
+----+-----+---
| 5  | 4   |
+----+-----+---
| 6  | 5   |
+----+-----+---
| 7  | 4   |
+----+-----+---
| 8  | 7   |
+----+-----+---
| 9  | 2   |
+----+-----+---

Wie kann ich alle Kinder einer bestimmten ID finden + die gesuchte?

Kann man dies per Datenbank ermitteln?

Wenn ich z.B. 4 angebe, möchte ich die IDs 4, 5, 6 7 und 8 als Ergebnis, bei der ID 7 die IDs 7 und 8.

Mir fehlt im Moment jeder Ansatz.

Melanie G.

[ChrisB]

Hi,

Mir fehlt im Moment jeder Ansatz.

Stichwort: Nested Sets

MfG ChrisB

[Melanie G.]

Hallo!

Mir fehlt im Moment jeder Ansatz.

Stichwort: Nested Sets

danke

wie kann ich bei l und r die Integrität sicherstellen?

Melanie G.

[Frank (no reg)]

Guten Morgen,

wie kann ich bei l und r die Integrität sicherstellen?

Z.b. durch Transaktionen während du Updates an der Struktur fährst.

Updates == auch Inserts. Ein Update in einem Nested Set besteht imho immer aus 3 einzelnen SQL Update/Insert Anweisungen. Diese sollten "atomar" gemacht werden, entweder alle 3 sind erfolgreich oder keines.

Gruss, Frank

[Melanie G.]

Hallo!

wie kann ich bei l und r die Integrität sicherstellen?

Z.b. durch Transaktionen während du Updates an der Struktur fährst.

Updates == auch Inserts. Ein Update in einem Nested Set besteht imho immer aus 3 einzelnen SQL Update/Insert Anweisungen. Diese sollten "atomar" gemacht werden, entweder alle 3 sind erfolgreich oder keines.

ich habe etwas mit DB_NestedSet "rumgespielt". DB_NestedSet verwendet eine lock-Tabelle, ich gehe mal davon aus, dass es Transaktionen dann nicht unterstützt.

Melanie G.

[dedlfix]

Hi!

Stichwort: Nested Sets
danke

Sich Nested Sets bei solchen Baumstrukturen anzusehen lohnt sich immer. Ob sich deren Einsatz lohnt, kommt auf die Umstände an. NS sind aufwendig beim Ändern der Menge, da dabei viele Datensätze angefasst werden müssen. Änderungsstatements sind auch recht komplex, das notwendige Atomarisieren wurde schon erwähnt. Neben Transaktionen kann auch die Billigvariante mit Table-Locking in Frage kommen. MySQL kann Transaktionen nämlich nicht mit der verbreiteten MyISAM-Engine aber mit InnoDB. Auf der anderen Seite können Teilbereiche aus NS oftmals mit nur einem SQL-Statement abgefragt werden, was recht effizient ist, aber auch teilweise recht komplexe Statements erfordert.

Je nachdem, was du insgesamt vorhast, kann auch ein Serialized LOB eine Lösung sein. Vor allem, wenn der Datenbestand recht klein ist. Dabei wird die komplette Datenstruktur (beispielsweise ein (verschachteltes) Array in PHP) in einen String serialisiert und dieser gespeichert. Beim Lesen braucht man nur zu unserialisieren und hat die Struktur gleich fix und fertig vorliegen. Die Datensätze in Einzelteilen im DBMS abzulegen erfordert ja auch üblicherweise (egal ob NS oder Parent-Verweise) nach dem flachen Lesen, sie passend im Baum einzuhängen.

Lo!

[Melanie G.]

Hallo!

Stichwort: Nested Sets
danke

Sich Nested Sets bei solchen Baumstrukturen anzusehen lohnt sich immer. Ob sich deren Einsatz lohnt, kommt auf die Umstände an. NS sind aufwendig beim Ändern der Menge, da dabei viele Datensätze angefasst werden müssen. Änderungsstatements sind auch recht komplex, das notwendige Atomarisieren wurde schon erwähnt. Neben Transaktionen kann auch die Billigvariante mit Table-Locking in Frage kommen. MySQL kann Transaktionen nämlich nicht mit der verbreiteten MyISAM-Engine aber mit InnoDB. Auf der anderen Seite können Teilbereiche aus NS oftmals mit nur einem SQL-Statement abgefragt werden, was recht effizient ist, aber auch teilweise recht komplexe Statements erfordert.

ich habe etwas mit DB_NestedSet "rumgespielt". Das funktioniert soweit ganz gut.

DB_NestedSet verwendet eine lock-Tabelle, ich gehe mal davon aus, dass es Transaktionen dann nicht unterstützt.

Je nachdem, was du insgesamt vorhast, kann auch ein Serialized LOB eine Lösung sein. Vor allem, wenn der Datenbestand recht klein ist. Dabei wird die komplette Datenstruktur (beispielsweise ein (verschachteltes) Array in PHP) in einen String serialisiert und dieser gespeichert. Beim Lesen braucht man nur zu unserialisieren und hat die Struktur gleich fix und fertig vorliegen. Die Datensätze in Einzelteilen im DBMS abzulegen erfordert ja auch üblicherweise (egal ob NS oder Parent-Verweise) nach dem flachen Lesen, sie passend im Baum einzuhängen.

was meinst Du mit Serialized LOB?

Melanie G.

[dedlfix]

Hi!

ich habe etwas mit DB_NestedSet "rumgespielt". Das funktioniert soweit ganz gut.
DB_NestedSet verwendet eine lock-Tabelle, ich gehe mal davon aus, dass es Transaktionen dann nicht unterstützt.

Vermutlich ist das so. Denn MySQL unterstützt Transaktionen nur mit der InnoDB-Engine, nicht mit der MyISAM-Engine. (Beim Erstellen von Tabellen kann man die Engine angeben.) Weiterhin sind die PEAR-DB-Pakete in der Regel so ausgelegt, dass sie mit vielen DBMS zusammenarbeiten. Da muss man Kompromisse schließen. Die einen können keine Transaktionen, der Lock-Mechanismus ist überall anders und so weiter und so fort. Da ist es einfacher (aber sicher weniger performant) ein eigenes System aufzusetzen.

Die Entscheidung liegt bei dir: Verwende das generelle Paket, such dir ein spezialisiertes oder nimm nur die Ideen und implementiere eigene Querys, angepasst an dein DBMS (und ggf. Storage-Engine).

Je nachdem, was du insgesamt vorhast, kann auch ein Serialized LOB eine Lösung sein. Vor allem, wenn der Datenbestand recht klein ist. Dabei wird die komplette Datenstruktur (beispielsweise ein (verschachteltes) Array in PHP) in einen String serialisiert und dieser gespeichert. Beim Lesen braucht man nur zu unserialisieren und hat die Struktur gleich fix und fertig vorliegen. Die Datensätze in Einzelteilen im DBMS abzulegen erfordert ja auch üblicherweise (egal ob NS oder Parent-Verweise) nach dem flachen Lesen, sie passend im Baum einzuhängen.

was meinst Du mit Serialized LOB?

Hab ich doch erklärt. Den Begriff hab ich mir auch nicht grad eben erst ausgedacht, man findet dazu auch Information. LOB steht für Large OBject. Serialisiert ist unter PHP das, was serialize() als Ergebnis liefert. Das ist ein String, der eine fertig aufgebaute Datenstruktur repräsentiert. Ein unserialize() auf den String und schon hat man die Datenstruktur wieder. Eignet sich um komplexe Datenstrukturen abzulegen, bei denen man im Ablagemedium nicht auf die Einzelteile zugreifen möchte/muss.

Lo!

[Frank (no reg)]

Hi,

LOB kann auch Line-Of-Business (Applikationen) sein ... dieses Buzzword höre ich in letzter Zeit recht häufig, zu häufig eigentlich. ;-)

Serialisierte Objekte sind sicher nicht schlecht, ich könnte mal pfo-forma noch XML empfehlen für komplexere Strukturen. Habe vor Jahren mal ein Fragebogensystem entwickelt, in welchem wir die Fragebögen in XML als Dokumente abgebildet hatten. Gerade für Vererbung von Inhalten aus Master-Fragebögen war das sehr effizient, verglichen mit dem zuerst gebastelteten SQL/Tabellen-basierten Prototypen. Selbiger basierte auf Nested Sets. (Das war dem Projektleiter dann aber zu viel Logik in der Datenbank ;-) und so musste was neues her).

Cheers, Frank