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.

    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


Anmelden zum Antworten