IBM pureXML, en proprietær XML-database bygget på en relationsmekanisme (designet til ordspil), der tilbyder både relationelle (SQL/XML) og ustrukturerede (XQuery) forespørgselssprog, og MarkLogic, en database bygget af scratch på basis af et nyt databaseparadigme (kald det NoSQL hvis du vil), der forstår ustrukturerede data og tilbyder ustruktureret forespørgselssprog ( XQuery ).
En anden vigtig information er den nye trend blandt NoSQL-databaseudbydere til implementering af SQL (eller SQL-lignende grænseflader). Et eksempel er den nylige promovering af Cassandra med CQL eller endnu mere modne SQL-grænseflader baseret på Hadoop.
Når to verdener støder sammen
NoSQL om Ingen SQL . For mig betyder det, at man flytter vægten til ikke-relationelle databasealternativer, som måske endda udforsker forskellige grænseflader til databasen (og er ligeglade med politisk korrekthed). Det er en god ting! Indrømmer du blindt SQLs svaghed for erhvervslivet? Tja, selvom SQL er det rigtige valg for dit produkt, skal du stadig tænke over konsekvenserne og sørge for, at tingene er godt afstemt mellem de to verdener. Med andre ord betyder det at fjerne den "blinde" del og reducere "halt" til et acceptabelt minimum for dine udviklere.
Datamodel
I relationel har du:
RowSet -> SQL -> RowSet
RowSet er sådan noget:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Jeg vil fortælle dig om XPath-datamodellen:
XDM -> XPath/XQuery -> XDM
Og XDM er sådan noget:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Begge er forenklede, men tjener et formål) .
Et karakteristisk træk ved datamodellen for dokumentet er, at træerne ikke er flade:
{
"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."
}
}
Der er således mange fortolkninger af, hvad dette kan betyde:
SELECT comments from PERSON where handle = "dscape"
Hvilket element af "kommentar" refererer anmodningen til? Hvis du ser på SQL / XML, vil din forespørgsel se sådan ud:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Dette fører til denne åbenlyse konklusion:træer har brug for en måde at navigere på. I XML er det XPath, i JSON er det måske JSONSelect, måske noget andet. Men du har stadig brug for standardnavigationsmetoden i første omgang.
Det, der gør denne opgave endnu mere interessant, er versionskontrol og kredsløbsudvikling. På trods af at dette er blevet ignoreret i evigheder i den relationelle verden (med alvorlige konsekvenser for erhvervslivet på grund af nedetid i disse sjove øjeblikke med bordskift). , dette skal faktisk ikke ignoreres for dokumenter. Tænk på Microsoft Word – hvor mange forskellige versioner af dokumenter understøtter de? Word 2003, 2005 osv.
Intet skema, fleksibilitet, ustruktureret:Vælg dit ord, men de er alle underlagt den hurtige udvikling af dataformater. I denne forespørgsel antager vi, at beskrivelsen er et menneskebarn, og at kommentarerne om, at jeg er en idiot, er en direkte efterkommer af træet. Dette vil helt sikkert ændre sig. Og SQL understøtter ikke versionering af dokumenter, så du bliver nødt til at udvide den for at få den til at fungere.
Det rigtige forespørgselssprog for ustrukturerede data skal tage højde for versionen. I XQuery kan vi udtrykke denne forespørgsel som sådan noget:
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
Frankenqueries, for eksempel
Nogen nævnte mig engang (taler om SQL / XML) som disse Frankenqueries. Udtrykket har klæbet mig til hovedet indtil videre. Lad os se lidt længere på denne analogi og se efter steder, hvor organiske dele og bolte mødes.
Lad os præsentere to indkøbslister, en til Joe og en til Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Nu med min "imaginære" SQL / JSON-udvidelse gør jeg:
SELECT apples
FROM LISTS
Hvad returnerer det? Husk, RowSet går ind, RowSet går ud?
2, 5
---
6
Selv hvis du eksplicit anmoder om en liste over æblenumre, får du to sæt rækker i stedet for tre, og et af rækkesættene vil have en liste med tal. Vælger du i stedet at returnere tre ting, får du to RowSet-sæt og tre RowSet-sæt. Jeg er ikke matematiker, men det lyder ikke godt.
Endnu en gang er det ikke et problem, hvis du bruger noget, der kan omhandle ustruktureret information. Du har ikke dette problem i javascript, og det vil selvfølgelig ikke være i XQuery. Både i javascript og i XQuery er det hele organisk.
Konklusion:fantastiske sprog til ustrukturerede data, enhjørninger og nissestøv!
Selvom XQuery er et fremragende sprog til ustruktureret information, beskytter mit synspunkt her ikke dets brug. Pointen, jeg forsøger at understrege, er behovet for et ægte sprog for ustrukturerede data, uanset hvordan du (læs:udviklere) vælger det.
Men jeg beder jer (udviklerne) om ikke at tage den "lamme SQL" tilbage. Hun er væk, og du har en ny hot date kaldet NoSQL. Bare giv det lidt tid, og det vil vokse på dig. Det er også meget sjovt at skrive JavaScript-kode, der fungerer i databaser:lad dem ikke tage den fra dig.
SQL til ustrukturerede data mislykkes. Så vil PL-SQL til ustrukturerede data mislykkes. Så hvis leverandøren insisterer på, hvad du har brug for, skal du ikke acceptere noget mindre end et fuldt programmeringssprog:du kan skrive din komplette ansøgning i javascript og gemme den i CouchApp, eller du kan skrive din komplette ansøgning i XQuery og gemme den i MarkLogic . Og sådan burde det være!
Her er en tjekliste over, hvad du skal kigge efter i forespørgselssproget for ustruktureret information:
- Sproget for navigationen
- Datamodel
- Normale udtryk
- Lambda
- Funktioner af høj orden
- Funktionel duft
- God linjebehandling
- Moduler, så du kan oprette dine egne biblioteker
- Applikationsserveren er klar over:har funktioner, der tjener REST
Du kan ignorere dette råd, men i sidste ende kan du føle dig frustreret over Silverlight-udvikleren. Og vi, de fyre, der kan lide at innovere i databaser, vil være skuffede over, at udviklerne besluttede at gå tilbage!