XML - ein Erklärungsversuch

[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.

[Popov]

Ich glaube was Stahli meint ist, dass es eine einfache und akzeptable Desktoplösung ist, weniger ob es eine gute Allgemein-Datenbank. Denn zum speichern einfacher Daten ist es mehr als ausreichend.

[stahli]

Nur mal zur Info:

Ich habe den Weg damals getestet um die Sinnhaftigkeit für mich einschätzen zu können. Grundsätzlich wollte ich Objektdaten persistieren.

Den Weg habe ich für mich wieder verworfen (würde auch eher ClientDatasets verwenden wenn es um Zugriff auf einfache XML-Strukturten geht).

Auf Grund einer Anfrage habe ich die Videos dennoch noch einmal heraus gesucht.

[chuckholdt]

Wir benutzen schon seit langen eine Architektur, die die Vorteile von "XML" und Datenbanken vereinigt. Heute würde man das wohl "noSQL-DB, document and graph-centric" nennen.

Im Prinzip werden alle Objekte als Dokument (XML oder JSON-ähnlich) gespeichert (in einer relationalen DB). Dazu kommen Verbindungen zwischen den Objekten. Damit lassen sich sowohl flexible als auch sehr effektive Systeme aufbauen. Unsere Anwendungen, die übrigens auch im Sportbereich liegen (überwiegend) und auch solche Dinge wie komplexe Turnierstrukturen abbilden, arbeiten mit Millionen von Objekten und entsprechend vielen Verbindungen. Wir haben 500+ Klassen (von für die User sichtbaren Objekten, intern natürlich viel mehr). Änderungen an Funkrionalitäten haben keinen Einfluss auf die DB-Struktur.

Das von dir angedachte Prinzip ist wohl nur sinnvoll (und da setzen wir es auch ein), wenn ein abgeschlossener Datensatz von nicht übertriebener Größe vorhanden ist und dieser transportiert (Server) oder einfach lokal gespeichert werden soll. Wir kombinieren das zum Teil mit obiger Architektur. Konfigurationen werden im obigen System gemacht, und danach komplett als XML z.B. für die Web-Anwendung oder die iphone-App zur Verfügung gestellt (Beispiel www.MyContractPro.de).

Chuck

MORE Projects