Datenbanken im XML Format - Ist das die Zukunft der Datenbanken?
-
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
