Eine auf sich selbst referenzierte Tabelle

Hi,
meinst Du sowas:

Bsp.:
Matrjoschkas
Jede Matrjoschka kann theoretisch in einer noch größeren stecken. Also könnte man ein Feld "ParentID" haben und dort die ID der übergeordneten Matrjoschka ablegen.
Man muss dabei natürlich aufpassen, dass man hier keine Schleifen baut.

?

E.

Sowas wird zum Beispiel für verkettete Listen verwendet bzw. um Entscheidungsbäume in einer "flachen" SQL Tabelle abzulegen.
Bei Entscheidungsbäumen gibt es eine variable Anzahl von Parent-Child Paaren, und vereinzelt findet man sowas auch in älteren ERP Programmen oder Addreßverwaltungen wo Addreßeinträge entweder quer untereinander referenziert sind oder über eine variable Anzahl von Gruppen und Gattungen sortiert sind.

Sobald so ein Tool es mal auf eine nennenswerte Verbreitung bringt sinken auch die Chancen, daß der Hersteller da nachträglich noch mal was dran ändert... die Abfrage solcher Tabellen ist "teuer", da man in der Regel vom letzten Child zum ersten Parent muß und diese Abfragen dann (meist) programmatisch generiert werden.

Moin blade999,

ich kann nur noch wenig zu den anderen Kommentaren ergänzen.

Die genannten Beispiele passen schon - bei (auch mehrstufigen) Hierarchien wie Mitarbeiter->Chef->Chefcheffe->Obercheffe oder Organisationsstrukturen etc ist es "logisch gesehen" genau diese Selbstreferenz.

Na ja, bei der Verwendung einer selbstreferenzierenden Tabelle wäre ich zögerlicher.
Im logischen Datenmodell existiert es öfter als tatsächlich als im physikalischen Datenmodell.
Nicht alle Datenbanksystem lassen eine Selbstreferenz als Constraint zu (also Foreignkey auf andere Tabelle ja, aber nicht auf die Tabelle, die dieses Constraint beinhaltet).

Außerdem ist diese Selbstreferenz ja auch (im logischen Modell) schon nicht so ganz eindeutig.
Bei so einem Standard-Fall einer Tabelle mit Selbstreferenz und den Feldern

• MitarbeiterID
• (Mitarbeiterdaten)
• VorgesetztenID (muss, wenn angegeben, eine MitarbeiterID in dieser Tabelle sein)

-> hier ist für jeden Mitarbeiter auch ein Verweis auf die VorgesetztenID vorhanden
-> die VorgesetztenID MUSS wiederum auch eine MitarbeiterID sein oder muss NULL bleiben
( das wäre ja die ganze Selbstreferenz-Regel)

Soweit logisch noch nachvollziehbar, auch die Erzeugung einer Hierarchie mit SQL-Mitteln aus den "flachen" Tabellendaten ist noch machbar.

Aber die üblichen Änderungen in dieser Tabelle, die meinetwegen die übliche Personalfluktuation in einer Firma abbilden soll, werden damit nicht richtig einfacher.
-> da führt dann zum diese Selbstreferenz schnell zu Komplikationen, die sich nur mit Programmieraufwand oder gar mit Nachdenken lösen lassen.
Eine einfache Regel "jeder Mitarbeiter muss genau einen Vorgesetzten haben, der auch Mitarbeiter der Firma ist oder eben keinen Vorgesetzten" ist zwar gut und richtig, aber hilft wenig bei den normalen Prozessen wie "Abteilungsleiter X, bisher Chef von Team 32, übernimmt jetzt einen anderen Bereich, ein Nachfolger für ihn wird gesucht".

Ende der Fahnenstange ist spätestens dann, wenn aus den Hierarchie-Bäumen "Netzpläne" Werden (ein Mitarbeiter hat mehrere Cheffes/arbeitet in mehreren Abteilungen). Ist nicht mehr trivial abzubilden.

Grüße
Biber

[Edit wegen neuem TO-Kommentar]
Ja, natürlich. Aufwand steigt exponentiell, auch für die Datenbank-Engine.
Wenn mit SQL-Mitteln aus einer flachen Tabelle ein Baum/eine Hierarchie abgeleitet werden soll-> das kostet.
Bau doch mal gedanklich aus einer Exceltabelle mit den Mitarbeitern dieser Firma die komplette Hierarchie auf.
Bei 2 Mitarbeitern lösbar, bei 70000 Mitarbeitern in 9 Hierarchie-Ebenen u.U. aufwändiger aufzudröseln.

Unter Umständen wäre eine Abbildung im der Datenbank mit mehreren Tabellen( eine Mitarbeitertabelle, eine Vorgesetztentabelle) weniger komplex als die selbstreferenzierende Mitarbeitertabelle.
[/Edit]

Oder einfach eine dritte Tabelle, welche die Verknüpfungen darstellt
z.B.
MasterID, SlaveID
oder
ParentID, ChildID

E.