IBM pureXML, eine proprietäre XML-Datenbank, die auf einem relationalen Mechanismus (ausgelegt für Wortspiele) aufgebaut ist, der sowohl relationale (SQL/XML) als auch unstrukturierte (XQuery) Abfragesprachen bietet, und MarkLogic, eine Datenbank, die daraus erstellt wurde auf der Basis eines neuen Datenbankparadigmas (nennen Sie es NoSQL, wenn Sie wollen) neu, das unstrukturierte Daten versteht und eine unstrukturierte Abfragesprache ( XQuery ) bietet.
Eine weitere wichtige Information ist der neue Trend unter NoSQL-Datenbankanbietern, SQL (oder SQL-ähnliche Schnittstellen) zu implementieren. Ein Beispiel ist die kürzliche Förderung von Cassandra mit CQL oder noch ausgereifteren SQL-Schnittstellen auf der Basis von Hadoop.
Wenn zwei Welten aufeinanderprallen
NoSQL über Kein SQL . Für mich bedeutet dies, den Schwerpunkt auf nicht-relationale Datenbankalternativen zu verlagern, die möglicherweise sogar andere Schnittstellen zur Datenbank ausloten (und sich nicht um politische Korrektheit kümmern). Das ist eine gute Sache! Die Schwäche von SQL for Business blind eingestehen? Nun, selbst wenn SQL die richtige Wahl für Ihr Produkt ist, müssen Sie dennoch über die Konsequenzen nachdenken und sicherstellen, dass die Dinge zwischen den beiden Welten gut aufeinander abgestimmt sind. Mit anderen Worten, es bedeutet, den „blinden“ Teil zu entfernen und „lahm“ auf ein akzeptables Minimum für Ihre Entwickler zu reduzieren.
Datenmodell
Im Verhältnis haben Sie:
RowSet -> SQL -> RowSet
RowSet ist ungefähr so:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Ich werde Ihnen etwas über das XPath-Datenmodell erzählen:
XDM -> XPath/XQuery -> XDM
Und XDM ist so etwas:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Beide sind vereinfacht, erfüllen aber einen Zweck) .
Eine Besonderheit des Datenmodells für das Dokument ist, dass die Bäume nicht flach sind:
{
"namespace": "person-2.0",
"comments": "This guy asked me for a dinosaur sticker. What a nutter!",
"person": {
"handle": "dscape",
"comments": "Please do not send unsolicited mail."
}
}
Daher gibt es viele Interpretationen dessen, was dies bedeuten kann:
SELECT comments from PERSON where handle = "dscape"
Auf welches Element von „Kommentar“ bezieht sich die Anfrage? Wenn Sie sich SQL / XML ansehen, sieht Ihre Abfrage so aus:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Dies führt zu dieser offensichtlichen Schlussfolgerung:Bäume brauchen einen Weg, um sich zurechtzufinden. In XML ist es XPath, in JSON könnte es JSONSelect sein, vielleicht etwas anderes. Aber Sie brauchen immer noch die Standard-Navigationsmethode.
Was diese Aufgabe noch interessanter macht, ist die Versionskontrolle und Schaltungsentwicklung. Obwohl dies in der relationalen Welt lange Zeit ignoriert wurde (mit schwerwiegenden Folgen für das Geschäft aufgrund von Ausfallzeiten in diesen lustigen Momenten des Tischwechsels). , das ist bei Dokumenten ja nicht zu vernachlässigen. Denken Sie an Microsoft Word – wie viele verschiedene Dokumentversionen werden unterstützt? Word 2003, 2005 usw.
Kein Schema, Flexibilität, unstrukturiert:Wählen Sie Ihr Wort, aber sie alle unterliegen der schnellen Entwicklung von Datenformaten. In dieser Abfrage gehen wir davon aus, dass der Deskriptor ein menschliches Kind ist und dass die Kommentare, dass ich ein Idiot bin, ein direkter Nachkomme des Baums sind. Das wird sich sicherlich ändern. Und SQL unterstützt keine Versionierung von Dokumenten, also müssen Sie es erweitern, damit es funktioniert.
Die eigentliche Abfragesprache für unstrukturierte Daten muss die Version berücksichtigen. In XQuery können wir diese Abfrage etwa so ausdrücken:
declare namespace p = "person-2.0" ;
for $person in collection('person')
let $comments-on-person := $person/p:comments
where $person/p:handle = "dscape"
return $comments-on-person
Frankenabfragen zum Beispiel
Jemand erwähnte mich einmal (über SQL / XML sprechend) als diese Frankenqueries. Der Begriff ist mir bisher im Kopf geblieben. Schauen wir uns diese Analogie etwas genauer an und suchen nach Stellen, an denen organische Teile und Schrauben zusammenkommen.
Lassen Sie uns zwei Einkaufslisten präsentieren, eine für Joe und eine für Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Jetzt mache ich mit meiner „imaginären“ SQL/JSON-Erweiterung:
SELECT apples
FROM LISTS
Was gibt es zurück? Denken Sie daran, RowSet geht rein, RowSet geht raus?
2, 5
---
6
Selbst wenn Sie also ausdrücklich eine Liste mit Apfelnummern anfordern, erhalten Sie zwei Sätze von Zeilen statt drei, und einer der Zeilensätze enthält eine Liste von Zahlen. Wenn Sie stattdessen drei Dinge zurückgeben, erhalten Sie zwei RowSet-Sätze und drei RowSet-Sätze. Ich bin kein Mathematiker, aber das klingt nicht gut.
Auch hier ist es kein Problem, wenn Sie etwas verwenden, das mit unstrukturierten Informationen umgehen könnte. Sie haben dieses Problem nicht in Javascript und natürlich nicht in XQuery. Sowohl in Javascript als auch in XQuery ist alles organisch.
Fazit:Atemberaubende Sprachen für unstrukturierte Daten, Einhörner und Feenstaub!
Obwohl XQuery eine ausgezeichnete Sprache für unstrukturierte Informationen ist, schützt mein Standpunkt hier nicht ihre Verwendung. Der Punkt, den ich zu betonen versuche, ist die Notwendigkeit einer echten Sprache für unstrukturierte Daten, egal wie Sie (sprich:Entwickler) sie wählen.
Aber ich bitte Sie (die Entwickler), das „lahme SQL“ nicht zurückzunehmen. Sie ist weg und Sie haben ein neues heißes Date namens NoSQL. Gib ihr einfach etwas Zeit und sie wird dir ans Herz wachsen. Es macht auch sehr viel Spaß, JavaScript-Code zu schreiben, der in Datenbanken funktioniert:Lassen Sie sich das nicht wegnehmen.
SQL für unstrukturierte Daten schlägt fehl. Dann schlägt PL-SQL für unstrukturierte Daten fehl. Wenn der Anbieter also darauf besteht, was Sie brauchen, akzeptieren Sie nicht weniger als eine vollständige Programmiersprache:Sie können Ihre vollständige Anwendung in Javascript schreiben und in CouchApp speichern, oder Sie können Ihre vollständige Anwendung in XQuery schreiben und in MarkLogic speichern . Und so sollte es sein!
Hier ist eine Checkliste, worauf Sie in der Abfragesprache für unstrukturierte Informationen achten sollten:
- Die Sprache der Navigation
- Datenmodell
- Normale Ausdrücke
- Lambda
- Funktionen höherer Ordnung
- Funktionaler Duft
- Gute Linienverarbeitung
- Module, damit Sie Ihre eigenen Bibliotheken erstellen können
- Der Anwendungsserver ist sich bewusst:hat Funktionen, die REST dienen
Sie können diesen Rat ignorieren, aber am Ende sind Sie möglicherweise frustriert über den Silverlight-Entwickler. Und wir, die Leute, die gerne in Datenbanken innovativ sind, werden enttäuscht sein, dass die Entwickler sich entschieden haben, zurückzugehen!
