nicht angemeldet
Hi,
also wenn das DBMS Unterabfragen in SQL-Queries zulässt, dann sollte das ganze kein Problem sein.
Angenommen, es gibt die Relation 'beziehung' (Attribute 'von', 'mit'), welche die m:n-Beziehung innerhalb von 'benutzer' (Primärschlüssel 'name') speichert. Für die zweite Ebene z.B. (die Beziehungen der Beziehungen) würde die Abfrage des Benutzers 'dummy' dann lauten:
SELECT * FROM benutzer WHERE name IN
(SELECT mit FROM beziehung WHERE von IN
(SELECT mit FROM beziehung WHERE von='dummy')
)
Wie es sich mit der Performance verhält, kann ich nicht sagen. Aber wenn ich mir StudiVZ so anschaue, scheinen sie es so realisiert zu haben.
Ansonsten:
Würde ich die Laufzeit optimieren wollen, wäre mein Ansatz eine Auslagerung der Beziehungstabelle auf einen externen Rechner (ähnlich wie ein Data Warehouse periodisch zu festgelegten Zeiten). Den "Beziehungsbaum" würde ich aufgrund der Datenmenge nicht zwischenspeichern (vorberechnen). Das Auflistungen der Beziehungen bis zu einer beliebigen Ebene könnte man aber mit relativ einfachen Mitteln so optimieren (Stichwort: Hashtabellen), dass die Zeit für die Suche vernachlässigbar klein wäre (natürlich wäre hier C++ die Sprache erster Wahl). Der Webserver würde dann einfach nach den Namen bis zu Beziehungsebene n fragen. Ich glaube nicht, dass das ein ernsthaftes Problem darstellen würde. Natürlich wäre die Laufzeit exponentiell relativ zu n - aber heißt für so kleine n nicht, dass es ernsthafte Probleme gibt. :)
Viele Grüße,
Johannes Röckert