XML - ein Erklärungsversuch

[stahli]

Hallo alle,

seit ein paar Tagen beschäftige ich mich mit XML und werde mein derzeitiges Projekt nun von Firebird auf XML umstellen.
Ich bin durchaus begeistert, welche Möglichkeiten sich damit zu eröffnen scheinen.

Ich gehe davon aus, dass ich die Probleme, die sich für mein Projekt mit einer SQL-Datenbank gestellt haben, mit XML viel komfortabler lösen kann.
Hoffentlich zerschlagen sich diese Hoffnungen nicht noch irgendwann ;-(

Bisher habe ich XML weitestgehend immer einfach ignoriert, da ich das Konzept für Delphi-Programmierer nicht einordnen konnte und die Möglichkeiten nicht erkannt habe.

Daher habe ich nun mal (ich wollte das für mich ohnehin nochmal aufarbeiten) ein paar kleine Videos erstellt und will die Euch hier mal anbieten.
Ich denke, das meiste darin sollte richtig sein
Die Videos erheben keinen Anspruch auf Perfektion (auch ich nicht) - aber vielleicht sind sie für den Einstieg und zum ersten Verständnis mal besser als nix...

(Als "Tutorial" kann man das sicher nicht bezeichnen, daher hier im XML-Thread. Ich habe auch Fehlversuche u.ä. nicht entfernt - dafür sind die Videos aber kostenfrei erhältlich )

Die Themen:

0) vorab ganz kurz zu XML und XML-Schemas
schule0

1) XML-Datei für "Schulverwaltung" und einfache Abfragen
schule1

2) Benutzung des "XML-Datenbingungsexperten"
schule2

3) Id-Attribute und XPath-Abfragen
schule3

4) kurze Info zu meinen Xml-Komponenten (noch im Aufbau)
schule4


Rückmeldungen sind willkommen...

[XHelp]

Hab mir bis jetzt nur das erste Video angeguckt. Für die Einführung fehlt noch z.B. DTD (davon lässt sich auch gut eine Überleitung zu xsd finden) und auch solche Scherze wie CDATA (da diesbezüglich häufig Fragen auftauchen).
Aber eine gute Idee

[omata]

Zitat von stahli:

Ich gehe davon aus, dass ich die Probleme, die sich für mein Projekt mit einer SQL-Datenbank gestellt haben, mit XML viel komfortabler lösen kann.

Mit steigender Größe des Projektes wird dir vermutlich klar werden, was du mit einer SQL-Datenbank hattest. Was Datensicherheit und Sklaierbarkeit angeht, kann XML dir vermutlich nicht so stabil zur Seite stehen. Das mag bei wenig Daten noch händelbar sein, weil übersichtlich, aber mit steigendem Datenbestand wird das die Hölle werden. Mal ganz abgesehen von möglichen Optimierungen die nicht so ohne weiteres möglich sind. Die müssen alle selbst programmiert werden, was Fehler in die Anwendung bringen kann und lange Tests erforderlich macht. Innerhalb einer Datenbank sind solche Optimierungen ein Standardvorgang, der immer gleich, schnell zu sinnvollen Resultaten führt. SQL bietet eine lockere Kopplung zwischen Delphi und Datenbank. Mit XML ist eine sehr starre Kopplung vorhanden, die einem bei der Weiterentwicklung leichter im Weg stehen kann.

Wie auch immer, deine Informationen sind sehr interessant.

Ob dein eingeschlagener Weg dich wirklich glücklicher machen wird, wage ich aber zu bezweifeln. Allerdings kenne ich dein Projekt und im speziellen die Größe deiner Daten nicht. Ebenfalls ist nicht bekannt, ob du an deinem Projekt öfters etwas ändern bzw. erweitern musst. Kann ja sein, dass du das einmal erstellst und dann nie mehr etwas daran ändern musst, dann ist dein Weg optimal.

[Florian Hämmerle]

Hi!

Also mir gefällts . Das hin und wieder was nicht gleich klappt macht auch nichts - im Gegenteil finde ich. Dadurch wird man auf diese Fehler aufmerksam und macht sie selbst eher nicht mehr.

Schöne Grüße,
Florian

[Neumann]

Hallo,

hab mir 2 Videos angesehen; durchaus interessant. Wie und womit sind die Videos gemacht? So etwas könnte ich auch gut gebrauchen.

Gruß

Ralf

[Florian Hämmerle]

Camtasia 6

[stahli]

Also erst mal danke für die positive Resonanz!
Ich denke, Videos an sich sind immer ein ganz gutes Mittel für solche Infos - jedenfalls besser als seitenlange Erklärungen...
Leider habe ich zum Thema (insbesondere zu dem "XML-Experten") nur ein engl. gefunden.


@XHelp:
Ich wollte nur kurz einen Chrash-Einstieg erklären, was XML überhaupt ist und wie man das grundsätzlich unter Delphi nutzen kann.
Und mehr als das Gesagte weiß ich auch nicht wirklich (habe allerdings schon über beide Themen mal etwas gelesen )
Der wichtigste Aspekt ist sicher, dass man in die XML beliebigen Kram schreiben kann. Ob das dann letztlich einer zuvor geplanten Struktur entspricht, KANN man ggf. über eine Schema-Datei abprüfen lassen. Das ist halt ein völlig anderer Ansatz als mit "richtigen" Datenbanken.

@omata:
Das ist der dritte Weg und ich hoffe sehr, dass er mich glücklich macht! Also ich will meine Turnierverwaltung umstellen. Grundsätzlich arbeitet der Nutzer (Turnierveranstalter) mit meinem Programm mit Objekten. Er kann Spieler in Spiele ziehen, Spiele auf Felder etc, alles "haptisch".

Mein erster Versuch lief komplett mit Objekten. Datenobjekte haben Daten verwaltet, visuelle Objekte haben sie gebunden und die Daten angezeigt. Für das Speichern habe ich mir so eine Art erweiterte Ini erstellt. Zumindest konnte man mehr oder weniger strukturierte Daten in eine Textdatei schreiben. Das Problem wurden letztlich die Beziehungen der Datenobjekte untereinander. War ein Spiel fertig, mussten alle anderen Objekte ggf. ebenfalls Änderungen veranlassen, was (durch ... ähh ... unglückliche Umstände oft Probleme in Form von Rückkopplungen verursacht hat). Da die Daten im Speicher lagen und das Schreiben und Lesen von der Platte mehrere Sekunden dauerte, war ein Verbinden zweier Rechner (ein Rechner hätte als Auskunftssystem für die Spieler dienen sollen) nicht möglich.
Auf meiner Homepage sind ein paar Screenshots meiner Projekte, da ist die Objektnutzung schnell zu erkennen.

Der zweite Versuch: Firebird. Ich will also letztlich so etwas ähnliches wie die Delphi-IDE anbieten. Der Nutzer soll nicht mit Tabellen arbeiten, sondern mit Objekten, die er dynamisch erstellen kann (weiteres Turnier, Gruppe Mannschaft, Spieler etc) und die letztlich direkt in der Datenbank abgebildet werden. In der Datenbank sind auch die Wege abgebildet, die z.B. ein Sieger geht. Auch das wird bei der Konstruktion eines Turniers vom Nutzer vorab durch Klicks festgelegt. Hier kam ich im Moment mit meiner Firebird-Version nur sehr schwer weiter, da es viele unterschiedliche Möglichkeiten des Turnieraufbaus gibt. Ich denke mir, dass das mit einer definierten Baum-Objektstruktur in der Datenbank selbst einfacher wird.
Mein Hauptproblem waren aber gerade die Änderungen der Datenbank. Ich habe eine DB-Versionsnummer mitgeführt. Bei jedem geänderten Feld musste ich das an mehreren Stellen berücksichtigen. In der DB, im DB-Script für neue Turniere, in einem Differenzscript für ältere zu öffnende Turniere, in den DB-Schnittstellen usw.
Hier sollte die XML-Lösung toleranter sein, denke ich. Die Verbindung eines Auskunfts-PC ist natürlich unter Firebird gar kein Problem.

Die XML-Lösung: Bin ich gerade am Testen, aber sehr zuversichlich. Im Grunde ist das genau die Lösung zwischen den beiden obigen. Eine Anbindung eines Auskunfts-PC ist grundsätzlich möglich, indem am Arbeitsrechner bei erfolgten Änderungen das XML-File zyklisch gespeichert wird und die Datei von dem Auskunftssystem daraufhin neu geladen wird. Grundsätzlich funktioniert das (habe ich getestet), es bleibt nur die Frage, ob das für ein gesamtes Turnier noch schnell genug läuft. Es werden keine Millionen Datensätze verwaltet aber einige zig-Tausend Knoten werden es schon werden...
Alles weitere muss die Praxis zeigen, im Moment bin ich erst mal zuversichtlich (muss ja!)
Im Moment teste ich aus, ob die Schnittstellen des Experten auch für mein aktuelles Projekt taugen. Evtl. ist die Nutzung einer xsd etwas problematisch, zumindest habe ich den Verdacht, da im Gegensatz zu meinen bisherigen xml-Nutzungen einige komische Probleme auftreten. Grundsätzlich hatte ich mir vorgestellt, die xsd mit einem XML-Editor (testweise Altova) grafisch zu erstellen und davon dieSchnittstellen zu erzeugen - das wäre natürlich sehr komfortabel (und wäre mir auch die 400 Eu wert)!
Es gibt dabei allerdings (bisher) schwer einzuordnende Problemchen, wobei ich auch keine Infos finde, welche xsd.Strukturen der Experte eigentlich genau erlaubt und verkraftet...
Wenn es funktionieren würde, wäre es eine sehr komfortable Lösung: Die Struktur wird grafisch erstellt (Baumstruktur), die Schnittstellenobjekte erzeugt Delphi automatisch, eine direkte Knotenanbindung erlauben meine xmlControls (xmlEdit etc) und bestimmte Ereignisse (Ergebnisberechnungen, Spieler weiter schicken, Platzierungen berechnen usw) kann ich über Prozeduren anschieben, die die vom Experten erzeugten Knoten benutzen... Was will der Delphianer mehr?

@ Neumann:
Genau, Camtasia - kostet etwas ist aber genial! Ebenso SnagIt für ScreenShots.
Getestet hatte ich auch HyperCam und StreamCatcher (klein aber fein).

[stahli]

Auf Wunsch einer einzelnen Dame habe ich die Videos nochmal rausgekramt:
(Ich lehne aber jede Verantwortung ab! )

Schule0: http://youtu.be/yBCOFGIWM7Y
Schule1: http://youtu.be/XwaMDAMwK1M
Schule2: http://youtu.be/tZX6fXzyEE8
Schule3: http://youtu.be/K979tyzULqs
Schule4: http://youtu.be/udchH94uz3A

Statt dessen sollte man sich die Erklärung von Alister ansehen:
http://www.youtube.com/watch?v=l1Hs67jAcYE

Insgesamt sehe ich jedoch wenige Anwendungsgebiete, bei denen ich auf direkten XML-Zugriff setzen würde.

[hoika]

Hallo,

Wenn ein neues/geändertes Feld an vielen Stellen zu Anpassungen führt,
liegt doch nicht an FB, sondern am Programmierer ?

Heiko

[Hansa]

Der Spagat ist mir etwas zu gewagt. Zuerst richtige Datenbank (nicht mal nur Access ) und dann back to the roots, also Textdatei? Was soll denn besser werden, wenn auf alle DB-Features verzichtet wird ? Das könnte zwar besser werden, sofern man bei dem XML-Kram die Fehler beim DB-Design nicht macht. Richtigen Sinn macht das aber nicht wirklich.

Egal wie, es gibt da noch einen eventuell goldenen Mittelweg. Und der wäre TClientDataset. Damit lässt sich relativ leicht aus der DB lesen (quasi wie gewohnt beim Dataset), das Teil lässt sich allerdings u.a. (es gibt da einge Formate) wiederum so als XML abspeichern :

CdsDM.CDS.SaveToFile('C:\test\test.xml',dfXML); D.h., die Datenbank-Daten können per XML bearbeitet werden.