rekursiv lesen - stored procedures?

[Kalle_B]

Hallöle,

ich weiss nicht, wie ich eine Struktur in der Datenbank rekursiv lesen kann. Natürlich kann ich das prozedural abarbeiten, also jeden einzelnen Satz lesen und dann entscheiden, welcher der nächste ist.

Aber pfiffiger wäre es, wenn die DB das könnte. Meine Frage ist: Geht das - Und wenn ja, wie?

Ich möchte eine zunächst dreistufige Struktur abbilden:

• Sportverein (root)
• • TT Abt. Tischtennis
• • • Mitglied 1
• • • Mitglied 2
• • HB Abt. Handball
• • • Mitglied 1 (auch Mitglied bei TT)
• • • Mitglied 3

Datensätze in der Tabelle "objekte":
id Text
-- -------
25 Verein
32 Abt TT
06 Abt HB
12 Mitglied 1
78 Mitglied 2
31 Mitglied 3

Datensätze in der Tabelle "objektverknuepfungen":
id obj_id_1 obj_id_2
-- -------- --------
01       25       32
02       25       06
03       32       12
04       32       78
05       06       12
06       06       31

Ganz einfach wäre dann das "Einhängen" des gesamtes Sportvereins in den Gemeindesportbund, das "Umhängen" der TT- Abteilung an einen anderen Verein. Die Stufen sind nicht begrenzt.

Falls stored procedures bei MySQL 5 infrage kommen: Wo liegt der Vor- und Nachteil gegenüber einer Abarbeitung mit PHP?

Lieben Gruß und einen schönen Sonntag noch, Kalle

[Ilja]

yo,

es ist gerade bei solch spezifischen fragen immer wichtig, welches dbms unter welcher version du benutzt. mir ist nach deinen aussagen noch nicht ganz klar, ob mysql 5 schon gewählt ist oder einer der kandidaten ist ? oracle kann zum beispiel hirachische abfragen über relationale tabellen ausführen. die frage ist nur, steht bei dir das dbms schon fest oder ist da noch spielraum ?

aber jetzt zum eigentlich inhalt deines beitrages. deine probleme haben meiner meinung nach wenig mit rekursion zu tun, weil du einen design-fehler gemacht hast. du hast verschiedene entitäten einfach alle zumsammen in eine tabelle (objekte) gepackt, die ich voneinander trennen würde.

würdest du diese trennung wieder einführen, dann wäre deine abfrage ganz leicht über joins zu lösen, sprich:

• Tabelle Sportverbund
• Tabelle Verein
• Tabelle Abteilung
• Tabelle Mitglieder

zu klären wären dann noch die art der beziehungen der tabellen untereinander, zum beispiel kann ein mitglied bestimmt in mehreren abteilungen sein und eine abteilung kann mehrere mitglieder haben, etc.

Ilja

[Kalle_B]

yo,

es ist gerade bei solch spezifischen fragen immer wichtig, welches dbms unter welcher version du benutzt.

Also, da musste ich gerade mal den aktuellen Stand abfragen, der Provider ändert wohl gelegentlich.

im Web:
PHP 5.1.6 + MySQL 4.1.9

Lokal, Windows2000:
im Web: PHP 5.2.0 + MySQL 5.0.27

Damit scheiden die stored procedures wohl erstmal aus.

oracle kann zum beispiel hirachische abfragen über relationale tabellen ausführen. die frage ist nur, steht bei dir das dbms schon fest oder ist da noch spielraum ?

Habe als Programmierer zwar schon mit oracle gearbeitet, habe aber keine Ahnung, ob das kostenfrei ist wie MySQL und ob man das zum Provider hochladen kann nach Linux.

Wenn zweimal ja, wäre das interessant.

aber jetzt zum eigentlich inhalt deines beitrages. deine probleme haben meiner meinung nach wenig mit rekursion zu tun, weil du einen design-fehler gemacht hast. du hast verschiedene entitäten einfach alle zumsammen in eine tabelle (objekte) gepackt, die ich voneinander trennen würde.

Das habe ich bewusst gemacht, damit der Anwender selbst neue entitäten einrichten kann. Dein Vorschlag bleibt ja in einer vierstufigen Hirarchie stecken:

• Tabelle Sportverbund
• Tabelle Verein
• Tabelle Abteilung
• Tabelle Mitglieder

Unterhalb der Mitglieder gehe ich noch weiter und habe Fax- Verbindung, Telefon, Anschrift, ... alles entitäten.

Und wenn ich will, kann ich eine entität "Musiktitel" einrichten (in der Tebelle "Objektart") und jeder Person Lieblingstitel zuordnen, dem Verein seine Hymne.

Kalle

[Ilja]

yo,

Habe als Programmierer zwar schon mit oracle gearbeitet, habe aber keine Ahnung, ob das kostenfrei ist wie MySQL und ob man das zum Provider hochladen kann nach Linux.

mysql ist genauso wenig  kostenfrei wie oracle. zum einen kostest auch mysql, wenn es für kommerzielle zwecke genutzt wird und vielmehr die wartung ist niemals kostenlos. oracle zu testzwecken kann man sich "einfach" installieren. setzt du es aber im professionellen bereich ein, dann kostest es und das nicht zu knapp, wobei oracles strategie ist, dass du hintenraus wieder kosten sparst, weil ihr system ja so klasse ist. das lassen wir einfach mal so ohne bewertung stehen.

Das habe ich bewusst gemacht, damit der Anwender selbst neue entitäten einrichten kann.

da läuten bei mir alle alarmglocken. ich will es mal so sagen, wenn du die eierlegendevollmichsau des daten-designs gefunden hast, sag mir bescheid, ich will dann auch ein stück von dem kuchen abhaben. ;-)

ich glaube, es macht sinn einen cut zu machen und zu sagen, bis hierhin und nicht weiter. man kann sich sonst ganz schnell in etwas verrennen. eine datenbank bezieht sich immer nur auf eine bestimmte umgebung, wo alle relevanten daten im daten-design abgebildet werden. ändert sich die umgebung in der zukunft, so muss/sollte das design nachgebessert werden.

ich stand mal vor einer ähnlichen aufgabe und habe für systemadminsitratoren eine inventarierungsdatenbank aufgebaut. dort habe ich auch unterschiedliche hardware (monitor, drucker, rechner) in eine tabelle zusammengefasst. das war schon nicht einfach. du gehst aber noch ein paar schritte weiter und ich würde dir davon abraten. die eine abfrage, die du nun haben willst ist ein erstes vorzeichen von den problemen, die da auf dich zukommen werden. die attribute der einzelnen objekte in einer tabelle darstellen ist ein problem, hinzu kommen noch die ganzen beziehungen zwischen den jeweiligen objekten/entitäten und zwar in unterschiedlicher form. wie willst du das alles in einer tabelle unterbringen ?

was man machen kann, und was ich aktuell auch auf meiner derzeiten arbeitsstelle mache ist, man teilt die tabellen in einzelne module auf. aber das allein ist schon recht kompliziert. deine sache halte ich für nicht sinnvoll umsetzbar, lasse mich aber eines besseren belehren.

Ilja

[Frank (no reg)]

Hoi,

dort habe ich auch unterschiedliche hardware (monitor, drucker, rechner) in eine tabelle zusammengefasst. das war schon nicht einfach.

Könntest du dies evendudel kurz konkretisieren, wo du da die Probleme gehabt hast? Alle Attribute aller verschiedenen Objekte in dieselbe Tabelle zu bekommen?

hinzu kommen noch die ganzen beziehungen zwischen den jeweiligen objekten/entitäten und zwar in unterschiedlicher form. wie willst du das alles in einer tabelle unterbringen?

An der Stelle sollte man mindestens "eine" separate Tabelle für die Beziehungen erwägen. :)

Und übrigens: "Everything is an object" sprach der OO-Programmierer bevor er an einer Datenbank verzweifelte. ;)

Ciao, *mist-ist-echt-schon-wieder-Sonntag?* Frank

[King^Lully]

Und übrigens: "Everything is an object" sprach der OO-Programmierer bevor er an einer Datenbank verzweifelte. ;)

Habs zwar nicht ganz verstanden, hört sich aber lustig an. OO und DBSe mögen sich nicht so, klar.

King Lully,
der zudem Rekursionen auf DBS-Ebene immer meidet

[Frank (no reg)]

Antwortet er nicht mehr im majestätischen Plural? Da schau an!

Ciao, Frank

[King^Lully]

Antwortet er nicht mehr im majestätischen Plural? Da schau an!

Wir sind in der Tat einer der wenigen hochgestellten Aristokraten, die immer mal wieder ins Du verfallen. (So wie auch der Prügelprinz, der alte Proll.)