nicht angemeldet
Hallo !
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.
Ich glaube gerne, dass diese Datenstrukturbeschreibung für den Anwender leichter nachzuvollziehen ist, als eine wilde Ansammlung von 1:1, 1:n oder n:m Relationen zwischen x-und-zwanzig Datenbanktabellen.
Ich kann nur nicht glauben, dass ein auf XML-Dateien basierendes DBMS die Daten intern genauso verwalten kann ohne hinsichtlich der Performance hinter Lochstreifen ;-) zurückzufallen.
Tabellen sind in dieser Hinsicht meine ich einfach starrer - selbst bei optimaler
Relationierung.
Ich meinte nicht das es nicht ginge, meine Bedenken sind in erster Linie Performanceprobleme
aus einer XML Datei krieg ich in einem Zug eine Baumstruktur heraus , ...
Ich würde in diesem Punkt das genaue Gegenteil behaupten.
Man bekommt zwar in der XML-Datei in einem Zug eine Baumstruktur heraus, aber auch _genau_ eine. Sobald ich die Daten in einer anderen Relation ausgeben will, als in der XML vorgegeben, bin ich doch verraten und verkauft, oder nicht?
Bei einem relationalen Tabellenansatz habe ich die Daten "pur" gespeichert und kann stelle die Hierarchie, Struktur, Relation, oder wie immer man es nennen will, quasi zum Zeitpunkt der Abfrage her. Flexibler geht's nimmer.
hingegen mit SQL
krieg ich nicht ohne entweder Scriptseitige Sortierung / Merges, oder rekursion eine
Baumstruktur hin. Ausnahme hier sind eben neuere Konstrukte welche nicht Standardsql
sind und die gewisse Datenbanken wie Oracle bieten.
Oracle kenne ich nicht (Geldbeutelproblem) aber solange es noch auf dem Relationalen Datenbankmodell beruht, ist damit eine Baumstruktur nicht zu machen. Ob nun das Datenbankmanagementsystem (Oracle) mir eine interne Programmfunktion zur Nachbildung einer Baumstruktur bietet oder ob ich mir diese selbst schreibe, ist letztlich auch relativ wurst (Programmierkenntnisse vorausgesetzt).
[...]
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".
Und ich behaupte rotzfrech: "Das geht nicht!" ;-)
Ich zitiere 'mal Martin von weiter oben im Thread:
"Natürlich hat XML-auch Nachteile. So kann das Verhältnis von Verwaltungsdaten (Element-Tags) zu Nutzdaten (Element-Daten) ungünstig werden, was Datentransferraten nicht unbedingt zum Vorteile gereicht."
Wenn ich mir dann noch überlege, dass - wenn schon, denn schon - auch die Datenbank-Index-Dateien in XML abgefasst sein müssten, rollen sich mir die Fußnägel hoch. ;-)
Ich finde einen anderen Weg viel gefährlicher den viele gehen, nämlich, XML, oder relationale
Datenbanken, oder Objektorientierung ist ür alles geeignet, vielmehr ist alles von dem
nützlich für gewisse Anwendungen, nur halt jede hat Grenzen und Vorteile.
Wenn ich dich hier richtig verstehe willst du sagen, für jeden Einsatzbereich gibt es ein spezialisiertes und optimiertes Datenformat. Dann stimme ich dir vollends zu.
Ich sehe die Zukunft für XML - wenn überhaupt - als standardisiertes Datenaustauschformat. Nicht mehr und nicht weniger.
Irgendjemand meiner Meinung? *hoff* :-)
Gruß,
kerki