Datenbanken im XML Format - Ist das die Zukunft der Datenbanken?
-
~john schrieb:
hustbaer schrieb:
Wieso sollte das so sein?
XML generiert einen massiven Overhead ohne jeden Gewinn an Funktionalität. Wozu also das Ganze? XML als Austauschformat ergibt Sinn, aber nur dann wenn der Austausch relativ selten erfolgt. Die ganzen XML Formate für IPC sind nur Performance Killer.
Bestimmte Queries sind auf XML Datenbanken bzw. indizierte XML Spalten in klassischen Datenbanken oft schneller, als wenn man dasselbe mit Tabellen nachbilden würde.
Baumartige Strukturen sind in klassischen Datenbanken die Hölle.Das Erstellen/Updaten des Index kann einen Flaschenhals darstellen, wenn zu oft Daten geändert werden.
Genauso *kann* es ein Problem sein, dass XML Files grösser sind.
Es *kann* auch unnötig umständlich werden Updates auf XML-Spalten oder XML-Datenbanken zu machen.Es gibt aber IMO durchaus Anwendungsfälle wo XML Spalten und/oder XML Datenbanken praktisch sind.
Man muss auch immer die Entwicklungszeit beachten, und gerade da kann XML oft punkten. Ob nun in Datenbanken oder als IPC Standard. Alleine der Umstand dass XML Files ohne spezielle Tools lesbar und editierbar sind ist oft schon viel wert.
-
Dann kann man auch sqlite nehmen. Man braucht natürlich ein Extra Tool zum Erstellen der Tabellen, etc. aber letztendlich ist der Zeitaufwand verschwindet gering. Zusätzliche Tools braucht man anschließend im Betrieb nicht mehr.
Das Editieren nachdem die Datenbank angelaufen ist, stelle ich mir bei XML aber als denkbar schwierig vor. Stell dir vor, du willst eine neue Spalte einfügen.
-
SQLite kann auch Tabellen erstellen.
Beim Open prüfen ob die Datei/Tabelle existiert, notfalls erzeugen. No Prob.
-
Scheppertreiber schrieb:
SQLite kann auch Tabellen erstellen.
Beim Open prüfen ob die Datei/Tabelle existiert, notfalls erzeugen. No Prob.
Ich habe auch von SQLite gesprochen und meien Kritik richtete sich gegen XML Stuff.
-
Dann kann man auch sqlite nehmen. Man braucht natürlich ein Extra Tool zum Erstellen der Tabellen, etc. aber letztendlich ist der Zeitaufwand verschwindet gering. Zusätzliche Tools braucht man anschließend im Betrieb nicht mehr.
Seht praktisch ist da der SQLite Manager für den Fuchs. Genial ...
-
---- schrieb:
Dann kann man auch sqlite nehmen.
Hä? Von was redest du?
Ich rede davon, dass es praktisch sein kann, wenn man bestimmte Dinge ohne spezielles Tool lesen kann.
-
hustbaer schrieb:
Bestimmte Queries sind auf XML Datenbanken bzw. indizierte XML Spalten in klassischen Datenbanken oft schneller, als wenn man dasselbe mit Tabellen nachbilden würde.
Baumartige Strukturen sind in klassischen Datenbanken die Hölle.Aber auch beim Baumartigen Strukturen ist XML nur die zweitbeste Lösung. XML kann alles aber nichts richtig. (gut wäre noch zu ergänzen)
hustbaer schrieb:
Man muss auch immer die Entwicklungszeit beachten,
Das ist exakt der Grund weshalb eine modernen Textverarbeitung genauso träge ist, wie Wordstar auf einem CP/M System. Es wird sich viel zu wenig Gedanken darüber gemacht, wie schnell das Zeug am Ende läuft, und statt einen sauberen Ansatz zu wählen wird einfach 08/15 irgend etwas hingewurschtelt.
-
Das ist exakt der Grund weshalb eine modernen Textverarbeitung genauso träge ist, wie Wordstar auf einem CP/M System. Es wird sich viel zu wenig Gedanken darüber gemacht, wie schnell das Zeug am Ende läuft, und statt einen sauberen Ansatz zu wählen wird einfach 08/15 irgend etwas hingewurschtelt.
Du sprichst mir aus der Seele
-
Schon mal darüber nachgedacht, warum es so eine Sch... wie xml usw gibt,
anstatt Binärformate (genormt) für Datenaustausch ?
Je weniger Info in mehr Bytes gepackt wird, um so mehr Platten, Sicherungsbänder
usw können auch verkauft werden.Gleichzeitig msß die Hardware aufgerüstet
werden usw usw.
Man braucht doch nur mal ne alte Cobol- Anwendung mit ner neuen SAP-Anwendung
bei gleicher Fallzahl zu vergleichen -da wird einem (aus eigener Erfahrung)
einfach nur schlecht.
Einmal alle Beiträge auslesen - alt (IMS Z/OS COBOL) ca 30 Minuten.
Wir reden hier von ca 900.000 Konten mit ca 10 Buchungen pro Monat.
Jetzt - paralleisiert, weil der Tag halt nur 24 Stunden hat, mit
SAP - schön modern - und mit 6 App-Servern usw ca 2 Stunden.
Das ist Fortschritt - aber die Anzeige im SAP ist bunt, was ja heute wichtiger
ist, wie performante Anwendungen.
Schnittstellen zu SAP haben z. B seit einigen Jahren das IDOC-FOrmat.
Sprich - für 1 Information, z B die Telefonnumer werden 3 Segmente mit ca
90 Byte Vorspann verbraten.sprich 270 Byte für ein 20-Stelliges Feld - und
so zieht sich das durch.
Wenn man sich dann mal die Tabelleninfos des Datenbanksystems anschaut und
dabei feststellt, daß z. b ein einstelliges Feld mit varchar gespeichert wird,
sprich 2 Byte Längenfeld für nix pro Tabelleneintrag - hier teilweie 85.000.000 und mehr, da denke ich gerne an die alten Zeiten zurück, wo man bei
gepackten Datumsfeldern das Vorzeichen entfernte, um ein Byte zu sparen.
(x'0900502f' wurde zu x'900502' (EBCDIC Decimal))
-
Nimm BaseX (www.basex.org), die beste und performanteste XML Datenbank die es gibt.
-
eXalite schrieb:
Nimm BaseX (www.basex.org), die beste und performanteste XML Datenbank die es gibt.
Woher hast du diese Information? Die mir bekannten XML-Benchmarks sind zwar schon älter, kommen aber alle zu anderen Ergebnissen ...
Neugierige Grüße
