Aus folgendem Gründen.
Datenhaltung / Konsistenz
– Keine Fremdschlüssel in der Datenbank zu semantischen Abhängigkeiten
– Keine Datenintegrität erforderlich. Subnodes ohne nodes ohne weiteres möglich, weil nicht durch FKs in der DB abgesichert.

Verständnis

- Nur wer wirklich weiss, wie die Zusammenhänge sind, der kann diese aus dem Schema zurückholen

Dabei ist es so einfach:
- Ein Baum besteht aus Knoten und Blättern. Die Besonderheit bei diesem DOM Baum ist folgende, dass es eigentlich nur “Knoten” gibt, diese Knoten enthalten auch die eigentlichen Werte. Das heisst ein Knoten hat eine Doppelfunktion – was aber egal ist erstmal.

- Die Verbindung eines Vaterknotens zu seinem Sohnknoten ist graphisch durch eine Linie gegeben. Diese Linie gilt es “mit abzubilden” und schon ist der Zusammenhang für immer fest und eindeutig.

Wie macht man das?
- Was im Baum eine Verbindung war (Zeiger), wird jetzt sehr einfach durch einen Foreignkey abgebildet. Dieser Foreignkey ist sagen wir mal “bidirektional”, aka der Vater weiss wer sein Kind ist und das Kind wer sein Vater ist.

Als Tipp zum Einfügen in die Datenbank:
- Definiere den FK auf dem Kind
- Füge erst alle Väter ein (in der jeweiligen Höhe h des Baums)
- dann die Kinder auf der Ebene h+1

Gedanken machen sollte man sich allerdings noch über den Primärschlüssel, dieser könnte “einfach gedacht” ein zusammengesetzter Schlüssel aus Längengrad und Breitengrad sein – aber mal kurz überlegen, wenn über der örtlichen Batteriesammelstelle noch ein gelber Briefkasten hängt .

Lösung könnte sein, da wir für die FKs eh innodb Tabellen verwenden müssen (isam kann das noch nicht), dass man für diese Tabellen eine AutoIncrement spalte einführt. (Beim Insert einfach auf NULL lassen, mysql macht das schon).

Für Oracle könnte ein workaround eine Sequenz sein (die können noch kein AutoIncrement)