nicht angemeldet
Hallo Danie
Ich verstehe nicht was du damit meinst, klar könnte man theoretisch Zitate aus Vorgängerpostings vererben, aber was hat das mit objektorientierung zu tun?
Unter "ideal geeignet fuer objektorientierte Ansaetze" meine ich einfach, dass objektorientierte Ansaetze immer der Vorstellung einer Baumstruktur folgen. Und Threads haben eine Baumstruktur. Also scheinen sie fuer objektorientierte Ansaetze prima geeignet zu sein. (Kann natuerlich sein, dass dieser Syllogismus unerlaubt ist, aber in Logik war ich noch nie ne Leuchte ;-)
Ich kann mir auch mit Objektorientierung keinen Weg vorstellen, ohne Rekursion auszukommen.
Mit "objektorientierten Datenbanken" meinte ich natuerlich nicht DBs, die intern objektorientiert programmiert sind (das duerften wohl alle sein, die heute eine ernsthafte Rolle am Markt spielen). Ich meinte damit, dass die Datenhaltung in solchen DBs nicht mehr in verknuepften Tabellen erfolgt, sondern in Baeumen.
Eine Relation wie diese:
1. Name, Vorname, Strasse, Telefon, Personalnummer
2. Personalnummer, Kommenzeitpunkt, Gehenzeitpunkt
kann ja auch so ausgedrueckt werden:
Mitarbeiter
Name,
Vorname,
Strasse,
Telefon,
Personalnummer
Kommenzeitpunkt,
Gehenzeitpunkt
In der zweiten Darstellung wuerde sich halt ergeben, dass irgendwann nach 10 eifrigen Dienstjahren ca. 2000 mal "Kommenzeitpunkt" und "Gehenzeitptunkt" unterhalb von "Personalnummer" steht. Es handelt sich gewissermassen um einen Datensatz "Mitarbeiter", der immer groesser wird und nicht, wie bei Tabellen, durch eine bestimmte Anzahl Felder begrenzt ist. Diese Form der Abbildung ist halt auch diejenige, die das Konzept von XML vorsieht. Und es gibt meines Wissens neuere Datenbanken, die ihre Daten ebenfalls in dieser Form halten. Sicher muessen solche DBs ebenso ihre Indizes verwalten wie relationale, wenn sie effizient und schnell arbeiten sollen. Ob sie dazu rekursive Methoden verwenden oder nicht, davon hab ich keine Ahnung. Aber das Datenmodell ist eben ein anderes. Ich bin aber sicher, Michael wird uns dazu noch eine Abhandlung schreiben, wenn er das hier entdeckt ;-)
Genau das meine ich eigentlich, XML eignet sich perfekt für hierarchische Daten, hingegen sind querverknüpte Daten eher mühsam darzustellen im Vergleich zu relationalen Datenbanken welche dafür grosse Schwierigkeiten haben mit hierarchischen Daten.
Was die Relationen betrifft, so sind diese finde ich durchaus durch Hierarchie ersetzbar, ohne dass man Informationsverluste hat. Siehe Beispiel oben. Was aber bei XML noch dazu kommt, ist die Moeglichkeit, eine unbestimmte und wechselnde Anzahl von Feldern zu definieren. Der eine Mitarbeiter ist meinetwegen in einer Gewerkschaft, der zweite ist vorbestraft, und der dritte hat schon mal einen wichtigen Auftrag vermittelt. 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. Tabellen sind in dieser Hinsicht meine ich einfach starrer - selbst bei optimaler Relationierung.
Das einzige was XML noch fehlt (gibts in Ansätzen schon), ist ein sehr schneller Zugriff wie das bei Datenbanken der Fall ist.
Jepp - und genau das wird glaube ich derzeit nicht nur hier bei uns erkannt. Nachdem nun genug dem XML-Gott gehuldigt wurde und die Leute nun tatsaechlich anfangen, mit XML-Anwendungen ihre Erfahrungen zu sammeln, kommt eben die Realitaet der Performance wieder ins Spiel - von solchen Dingen ist natuerlich in keiner W3-Spec die Rede.
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".
viele Gruesse
Stefan Muenz