Das Design von Nested Sets ist definitiv schwierig, wenn Sie den Baum häufig aktualisieren müssen. Am Ende müssen Sie große Teile des Baums neu nummerieren.
Ein Vorschlag zur Abschwächung dieses Problems besteht darin, Gleitkommazahlen anstelle von Ganzzahlen zu verwenden. Wenn Sie einen neuen Knoten in den Baum einfügen, ist es relativ einfach, einige FLOAT-Nummern zwischen den verschachtelten Satznummern des übergeordneten Knotens des neuen Knotens zu finden. Möglicherweise stoßen Sie irgendwann an die Grenzen der Genauigkeit einer Fließkommazahl, aber da Ihr Baum nicht sehr tief ist, wird dies für lange Zeit nicht passieren.
Eine andere Technik, über die ich geschrieben habe, nenne ich Closure Table . Diese Methode zum Speichern von Hierarchien macht es viel einfacher, Knoten in einem großen Baum einzufügen/aktualisieren/löschen, ohne einen Großteil Ihres Baums aktualisieren zu müssen. Und Sie können immer noch den gesamten Baum oder einen Teilbaum in einer einzigen nicht-rekursiven SQL-Abfrage abfragen.
Um mehr über Abschlusstabellen zu erfahren, siehe:
- Was ist der effizienteste/eleganteste Weg, eine flache Tabelle in einen Baum zu parsen?
- Modelle für hierarchische Daten mit SQL und PHP
- Teilbäume in Abschlusstabellenhierarchien verschieben
- SQL-Antipatterns:Vermeidung der Fallstricke der Datenbankprogrammierung
Zu Ihrem Kommentar:
Die Adjazenzliste ist einfach, weist ein Minimum an Redundanz auf und unterstützt FK-Beziehungen, was bei verschachtelten Mengen nicht der Fall ist. Adjacency List unterstützt die Abfrage eines ganzen Baums beliebiger Tiefe, wenn Sie rekursive Abfragen verwenden . Aber MySQL unterstützt keine rekursiven Abfragen.
Wenn Sie nur unmittelbare Eltern-Kind-Beziehungen abfragen müssen (d. h. eine Tiefe der Ebene) oder ansonsten nur Bäume mit fester Tiefe abfragen müssen, dann ist Adjacency List in Ordnung.
