SQL/XML-Standard in MySQL
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
abfrage
anbieter
beispiel
datei
datenbank
datum
dokument
erfahrungsbericht
http
idee
nachteil
orientieren
server
setzen
speichern
standard
teil
transformation
url
version
-
Hallo!
Es gibt einen Teil im SQL-Standard, der sich damit beschäftigt den Brückenschlag zwischen relationalen Daten (SQL) und strukturierten Daten (XML) zu meistern. Es handelt sich dabei um den SQL/XML-Standard. Hier wird definiert, wie man aus relationalen Daten XML-Daten und aus XML-Daten relationale Daten erhält. Außerdem ermöglicht der Standard die Abfrage von XML-Daten aus persistierten XML-Daten.
Die großen DB-Anbieter wie IBM und Oracle orientieren sich sehr stark am Standard und setzen diesen auch mehr oder weniger konform um. Nur Microsoft orientiert sich eher weniger an diesem Standard. MySQL ist von einer Standardkonformität noch weit weg, soll aber in späteren Versionen (7?) ebenfalls konform sein.
Meiner Meinung nach scheint dies sinnvoll zu sein, da XML immer verbreiteter wird und für den Austausch von Daten über das Web genutzt werden kann und auch wird. Die auszutauschenden Daten befinden sich aber meist in relationalen Datenbanken.
Mich würde nun interessieren, was die Lima-City-Gemeinde von diesem Standard hält und welche Ideen bzw. Erfahrungen über Einsatzmöglichkeiten die Gemeinde schon hat. Sollte MySQL den Standard eher schneller umsetzen oder doch erst mit einer späteren Version?
Danke für eure zahlreichen Rückmeldnugen!
Beitrag zuletzt geändert: 7.4.2010 7:45:41 von wagnerm -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Du verwechselst da einige Dinge. MySQL ist standard-konform, die Datenbank von Microsoft heißt MSSQL und ist die, welche nicht 100%ig den SQL-Standard verfolgt.
XML und SQL haben absolut nichts miteinander zu tun. Du kannst zwar bei beiden Daten speichern, das eine ist eine Umschreibungssprache für XML-Dateien, die andere Sprache ist dafür zuständig mit Datenbanken zu agieren (Datensätze, Tabellen und Spalten einfügen, abfragen, ändern usw.).
Der Unterschied zwischen diesen beiden ist, dass die Datenbanken ein festes Schema haben, XML-Dateien dagegen beliebig gefüllt werden können. Beides hat Vor- und Nachteile. Ein Trend geht momentan in Richtun NoSQL-Datenbanksysteme, einige davon verwenden auch XML-Dateien um die Daten zu sichern. -
Nein, nein. Ich verwechsle hier nichts. Ich habe mich hier unglücklich ausgedrückt:
Die großen DB-Anbieter wie IBM und Oracle orientieren sich sehr stark am Standard und setzen diesen auch mehr oder weniger konform um. Nur Microsoft orientiert sich eher weniger an diesem Standard. MySQL ist von einer Standardkonformität noch weit weg, soll aber in späteren Versionen (7?) ebenfalls konform sein.
Sollte besser lauten:
Die großen DB-Anbieter wie IBM und Oracle orientieren sich sehr stark am Standard und setzen diesen auch mehr oder weniger konform um. Nur Microsoft orientiert sich mit seinem SQL Server eher weniger an diesem Standard. Auch MySQL von Sun ist von einer Standardkonformität noch weit weg, soll aber in späteren Versionen (7?) ebenfalls konform sein.
Also, dass XML und SQL zwei verschiedene Paar Schuhe sind, ist mir klar. Nur sind historisch gesehen sehr viele oder sogar die meisten Daten in relationalen Datenbanken gespeichert. XML hat sich aber zu dem meist verwendeten Format zum Datenaustausch über das Web etabliert. Nicht umsonst gibt es einen eigenen Teil im SQL-Standard, der versucht die beiden Konzepte SQL und XML zu kombinieren bzw. zu vereinen.
Meiner Meinung nach ist SQL/XML ein Teilbereich von noSQL. Denn XML-Datenbanken werden in Wikipedia als Kategorie von noSQL angeführt (vgl. http://en.wikipedia.org/wiki/NoSQL#Taxonomy). Die XML-Datenbanken kann man wiederum in XML-fähige Datenbanken und native XML-Datenbanken kategorisieren. Der SQL/XML-Standard standardisiert den Teilbereich XML in (objekt-)relationalen XML-fähigen Datenbanken.
Natürlich hat alles Vor- und Nachteile. Diese würde ich gerne aus Erfahrungsberichte und Ideen von Benutzern eruieren. -
wagnerm schrieb:
Natürlich hat alles Vor- und Nachteile. Diese würde ich gerne aus Erfahrungsberichte und Ideen von Benutzern eruieren.
Moment, du verwechselst auf der einen Seite Storage mit Transfer. Klar lohnt sich XML sehr gut zum Datenaustausch (wie es auch zB mit XHTML <=> Browser oder RSS <=> Rss-Reader) super funktioniert. Ob es sich lohnt, die Daten, die man austauschen will, auch in XML zu speichern ist ein anderes Thema. Darum verwenden Webseiten oft andere Datenbanken, jedoch nur um die Daten zu speichern. SQL-fähige Datenbank <=> Query <=> Output (XML). Ob nun die Datenbank direkt XML ausgibt oder ein Script dazwischen steht (zB PHP) ist irrelevant. Da immer häufiger Webseiten auf Ajax basieren und sich daher JSON statt XML anbietet, werden andere Alternativen in Betracht gezogen, die direkt JSON zurück geben (zB die Ansätze der NoSQL-Datenbanken). Eine Datenbank, die jedoch direkt XML ausgibt (ohne dass ein Script dazwischen steht) hört sich jedoch auch interessant an, ich kenne die Änderungen für MySQL Version7 jedoch nicht und habe bereits nix darüber gehört. Kannst du hier ein paar Quellen nennen? -
Der Standard sieht einen eigenen SQL-Datentyp in der Datenbank vor, der es erlaubt XML-Dokumente bzw. Teile davon als XML abzuspeichern. Weiters können relationale Daten als XML puliziert werden (mit dafür vorgesehenen SQL-Funktionen wie zB XMLElement) oder aus abgespeicherten XML-Daten relationale Daten gewonnen werden (mit dafür vorgesehenen SQL-Funktionen wie zB XMLQuery, die eine XQuery-Anfrage in SQL erlaubt).
Wobei mE Ersteres am häufigsten genutzt werden wird. Der Vorteil dabei ist mM nach, dass die Speicherung und Abfrage in der Datenbank selbst von statten geht, die dafür optimiert und performant sind, und nicht im eigenen Code zwischen SQL<->XML und XML<->SQL hin und her transformiert werden müssen. In diesem Fall kann daher Performance gewonnen werden.
Natürlich kommt immer alles auf die konkrete Anwendung (XML-Speicherung, XML-Generierung,...) drauf an, ob es wirklich sinnvoll und performant ist. Das muss immer im konkreten Fall bewertet werden. Vermutlich lohnt es sich für Neuentwicklungen eher weniger, aber für alte Datenbestände, die sich über Jahrzehnte hinweg aufgebaut haben, können oft nicht so einfach portiert werden. Aus wirtschaftlicher Sicht könnte da SQL/XML Abhilfe schaffen.
Die von dir gewünschten Quellenangaben aus dem Worklog von forge.mysql.com:
http://forge.mysql.com/worklog/task.php?id=3414
(Hier wird der SQL/XML-Standard aus dem Jahre 2007 angesprochen.)
http://forge.mysql.com/worklog/task.php?id=2410
(Wobei sich dieser Task an den SQL Server von Microsoft orientiert und dieser nicht standardkonform ist.)
Beitrag zuletzt geändert: 7.4.2010 16:27:49 von wagnerm -
wagnerm schrieb:
(Wobei sich dieser Task an den SQL Server von Microsoft orientiert und dieser nicht standardkonform ist.)
Vermutlich bin ich deshalb noch nicht darüber gestolpert, ich habe MSSQL noch nicht in diesem Zusammenhang zu tun gehabt. An sich finde ich die Überlegungen hinter SQL/XML super und wenn man tatsächlich XML ausgeben möchte kann man die Daten entsprechend dem XML-Dokument ablegen.
Wenn ich jetzt aber aus der Sicht eines Webentwicklers ausgehe müsste man die Daten dennoch transofmieren, da man die Daten nur selten so vorliegen hat, dass das entsprechende XML-Dokument (sei es XHTML oder RSS) direkt aus der Datenbankstruktur ableiten kann. Zum Beispiel sind News nicht nach RSS gespeichert sondern werden nach RSS ausgelesen. Das hängt dann natürlich auch von der eingesetzten Software zB CMS ab. Würde es evtl. Sinn machen, die Daten als XML auszulesen und über XSLT dann entsprechent (zB News aus der DB zu RSS) zu transfomieren? Aber selbst dann steht ein Script dazwischen, nur die Art der Transformation ist eine andere. Wenn man jedoch mit einem eigenen XML-Format arbeitet, ist SQL/XML sicherlich eine gute Lösung. -
trueweb schrieb:
Wenn ich jetzt aber aus der Sicht eines Webentwicklers ausgehe müsste man die Daten dennoch transofmieren, da man die Daten nur selten so vorliegen hat, dass das entsprechende XML-Dokument (sei es XHTML oder RSS) direkt aus der Datenbankstruktur ableiten kann. Zum Beispiel sind News nicht nach RSS gespeichert sondern werden nach RSS ausgelesen. Das hängt dann natürlich auch von der eingesetzten Software zB CMS ab. Würde es evtl. Sinn machen, die Daten als XML auszulesen und über XSLT dann entsprechent (zB News aus der DB zu RSS) zu transfomieren? Aber selbst dann steht ein Script dazwischen, nur die Art der Transformation ist eine andere. Wenn man jedoch mit einem eigenen XML-Format arbeitet, ist SQL/XML sicherlich eine gute Lösung.
Die Struktur des mittles SQL/XML zu erzeugenden XML-Dokuments/-Fragments kann beliebig sein. Man kann mit einem entsprechenden SQL-Statement ein XML (zum Beispiel ein RSS-Dokument) aus relational abgespeicherten Daten generieren oder man speichert es als ganzes XML in der Datenbank ab und lädt es als ganzes in die Anwendung zur weiteren Verarbeitung. Eine Transformation mit XSLT ist zwar möglich aber nicht zwingend erforderlich. Ein RSS-Dokument kann nach Abfrage ohne jegliche Transformation auf Anwendungsebene sofort weiter verarbeitet werden.
Die zweite Variante wäre für ein RSS-Dokument vermutlich die bessere, da sich die Nachricht nicht verändern wird und somit nicht bei jedem erneuten Auslesen der Daten wieder Performance für das Erstellen des XML-Dokuments in Anspruch genommen wird. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage