nicht angemeldet
Hi Stefan,
Michael wird uns dazu noch eine Abhandlung schreiben, wenn er das hier entdeckt ;-)
Ach nee, gar nicht (vor allem, weil ich vom Innenleben 'richtiger' objektorientierter Datenbanken auch keine Ahnung habe - eigentlich würde es mich interessieren, aber irgendwie scheinen deren Hersteller den Internet-Crash voll abgekriegt zu haben, während die 'alten Hasen' wie Oracle und IBM das dank vorhandener Masse und geringerer Spezialisierung recht ordentlich aushalten).
Im Wesentlichen schließe ich mich Daniela an, daß beide Ansätze ihre deutlichen Vor- und Nachteile haben und daß es gefährlich ist, zu glauben, man könne mit einem Ansatz alle Probleme lösen. Ginge das, dann hätten wir heute beispielsweise nur eine Programmiersprache ...
Fuer all solche Sachen kann man problemlos mal in der DTD eines
XML-Datenbestandes zusaetzliche, optionale Elemente definieren,
die dann im Datenbaum eingefuegt werden koennen oder auch nicht.
Was ist daran flexibler, als eine zusätzliche Tabelle zu definieren und deren Inhalt bei Bedarf über einen gemeinsamen Schlüssel zu JOINen? Der wesentliche Unterschied ist m. E., daß Dir bei einer relationalen Datenbank die Zerlegung der Objekte ständig präsent ist, während Du bei XML in der Illusion lebst, alles sei sowohl geordnet als auch strukturiert - das mag ja semantisch der Fall sein, ignoriert aber in der Tat die Probleme der Realisierung.
Tabellen sind in dieser Hinsicht meine ich einfach starrer -
selbst bei optimaler Relationierung.
Eine 'richtige' relationale Datenbank würde für die zusätzliche Tabelle beispielsweise über Constraints eine kostenlose (praktisch kein Quelltext notwendig) und performante Wertemengenprüfung erlauben. Das geht bis zu Konstrukten, welche den Versuch des Entfernens eines Wertes der Wertemenge automatisch zurückweisen, wenn dieser Wert noch referenziert wird, oder sogar "delete cascading" machen, also alle abhängigen Werte automatisch mit entfernen.
Was Datenkonsistenz angeht, haben sich die relationalen Datenbanken schon mit einer ganzen Reihe von Problemen erfolgreich befaßt. Und das bezieht sich keineswegs nur auf Performance, sondern genauso auf Semantik.
Ich mag keine externen Anwendungen, welche sich mit der Konsistenz der Daten befassen - ich will "intelligente Daten"! Mit einer 'richtigen' relationalen Datenbank, insbesondere mit Constraints und Triggern und stored procedures, macht man die Datenmodellierung genau _einmal_, und die Anwendungsprogramme haben damit nichts mehr zu tun. (Vor allem kann auch keines davon mehr "pfuschen" und sich an irgendwelchen Prüfungen vorbei mogeln.) Von einer Objektdatenbank würde ich dasselbe verlangen.
Trotzdem halte ich den W3-Weg fuer richtig: erst sich Gedanken
machen ueber die optimale Datenhaltung - und dann sagen: "tja,
nun sind andere dran, die sich drum kuemmern sollen, wie man das
akzeptabel schnell macht".
Das ist die Vorgehensweise, die in den letzten Jahren in vielen Bereichen erfolgreich eingesetzt wurde: "Wir optimieren das jetzt nicht - bis das Produkt fertig ist, haben die Anwender ohnehin die nächste CPU-Version im Einsatz." Das mag prima gehen, wenn Faktor 2-5 fehlt.
Aber bei Datenbanken besteht einfach immer die Gefahr, einen logarithmischen durch einen linearen oder einen linearen durch einen quadratischen Faktor zu ersetzen. Und was das bei Datenmengen mit großen einstelligen Dezimalwerten bedeutet, kannst Du leicht ausrechnen - ein full table scan gegenüber einem Indexzugriff ist nur bei überschaubaren Datenmengen tolerierbar. (Das Forum-Archiv mit 10^6 Datensätzen ist da ungefähr der Grenzbereich, wie wir im praktischen Einsatz erleben - bei zehn- oder hundertmal so vielen Daten wäre die aktuelle Archivsuche nicht mehr brauchbar, über Indexzugriffe wären aber mehrere Zehnerpotenzen zu gewinnen.)
Wenn man da auch nur an _einer_ Stelle so richtig daneben greift, dann kann es so immens teuer werden, daß "geht nicht" durchaus die einzig meßbare Geschwindigkeit ist.
Ich halte Deinen Ansatz, zuerst die Semantik und dann die Performance zu betrachten, durchaus für richtig - nur solltest Du nie vergessen, daß das Anwendungsgebiet dafür entsprechend gefährlich ist und daß eine kleine, harmlose Änderung der Aufgabenstellung den Gesamtaufwand beträchtlich beeinflussen oder gar das existierende Datenmodell in Frage stellen kann.
Viele Grüße
Michael