IBM pureXML, en proprietär XML-databas byggd på en relationsmekanism (designad för ordlekar) som erbjuder både relationella (SQL/XML) och ostrukturerade (XQuery) frågespråk, och MarkLogic, en databas byggd från scratch på basis av ett nytt databasparadigm (kalla det NoSQL om du vill) som förstår ostrukturerad data och erbjuder ostrukturerat frågespråk ( XQuery ).
En annan viktig information är den nya trenden bland NoSQL-databasleverantörer för implementering av SQL (eller SQL-liknande gränssnitt). Ett exempel är den senaste marknadsföringen av Cassandra med CQL eller ännu mer mogna SQL-gränssnitt baserade på Hadoop.
När två världar kolliderar
NoSQL om No SQL . För mig innebär detta att tyngdpunkten flyttas till icke-relationella databasalternativ, som till och med kan utforska olika gränssnitt till databasen (och inte bryr sig om politisk korrekthet). Det här är bra! Blint erkänner SQLs svaghet för företag? Tja, även om SQL är rätt val för din produkt, måste du fortfarande tänka på konsekvenserna och se till att saker och ting är väl anpassade mellan de två världarna. Med andra ord betyder det att du tar bort den "blinda" delen och minskar "halten" till ett acceptabelt minimum för dina utvecklare.
Datamodell
I relationellt har du:
RowSet -> SQL -> RowSet
RowSet är ungefär så här:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Jag kommer att berätta om XPath-datamodellen:
XDM -> XPath/XQuery -> XDM
Och XDM är något sånt:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Båda är förenklade, men tjänar ett syfte) .
En utmärkande egenskap hos datamodellen för dokumentet är att träden inte är platta:
{
"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."
}
}
Det finns alltså många tolkningar av vad detta kan innebära:
SELECT comments from PERSON where handle = "dscape"
Vilket element av "kommentar" avser begäran? Om du tittar på SQL / XML kommer din fråga att se ut så här:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Detta leder till denna uppenbara slutsats:träd behöver ett sätt att navigera på. I XML är det XPath, i JSON kan det vara JSONSelect, kanske något annat. Men du behöver fortfarande standardnavigeringsmetoden i första hand.
Det som gör denna uppgift ännu mer intressant är versionskontroll och kretsutveckling. Trots att detta har ignorerats i evigheter i relationsvärlden (med allvarliga konsekvenser för affärer på grund av driftstopp i dessa roliga ögonblick av bordsbyten). , detta ska verkligen inte ignoreras för dokument. Tänk på Microsoft Word – hur många olika versioner av dokument stöder de? Word 2003, 2005, etc.
Inget schema, flexibilitet, ostrukturerat:välj ditt ord, men de är alla föremål för den snabba utvecklingen av dataformat. I den här frågan antar vi att deskriptorn är ett mänskligt barn och att kommentarerna om att jag är en idiot är en direkt ättling till trädet. Detta kommer säkert att förändras. Och SQL stöder inte versionshantering av dokument, så du måste utöka den för att få den att fungera.
Det verkliga frågespråket för ostrukturerad data måste ta hänsyn till versionen. I XQuery kan vi uttrycka den här frågan som något sånt:
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, till exempel
Någon nämnde mig en gång (på tal om SQL / XML) som dessa Frankenqueries. Termen har fastnat i mitt huvud hittills. Låt oss titta lite längre på denna analogi och leta efter platser där organiska delar och bultar möts.
Låt oss presentera två inköpslistor, en för Joe och en för Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Nu med min "imaginära" SQL / JSON-tillägg gör jag:
SELECT apples
FROM LISTS
Vad ger det tillbaka? Kom ihåg att RowSet går in, RowSet går ut?
2, 5
---
6
Således, även om du uttryckligen begär en lista med äppelnummer, får du två uppsättningar rader istället för tre, och en av uppsättningarna med rader kommer att ha en lista med nummer. Om du istället väljer att returnera tre saker får du två RowSet-set och tre RowSet-set. Jag är ingen matematiker, men det låter inte bra.
Återigen är det inte ett problem om du använder något som kan hantera ostrukturerad information. Du har inte det här problemet i javascript och det kommer naturligtvis inte att vara i XQuery. Både i javascript och i XQuery är allt organiskt.
Slutsats:fantastiska språk för ostrukturerad data, enhörningar och nissedamm!
Även om XQuery är ett utmärkt språk för ostrukturerad information, skyddar min synpunkt här inte dess användning. Poängen jag försöker betona är behovet av ett riktigt språk för ostrukturerad data, oavsett hur du (läs:utvecklare) väljer det.
Men jag ber er (utvecklarna) att inte ta tillbaka den "lama SQL". Hon är borta och du har ett nytt hett dejt som heter NoSQL. Ge det bara lite tid så växer det på dig. Det är också väldigt roligt att skriva JavaScript-kod som fungerar i databaser:låt dem inte ta den ifrån dig.
SQL för ostrukturerad data kommer att misslyckas. Då kommer PL-SQL för ostrukturerad data att misslyckas. Så om leverantören insisterar på vad du behöver, acceptera inte något mindre än ett fullständigt programmeringsspråk:du kan skriva din fullständiga ansökan i javascript och spara den i CouchApp, eller så kan du skriva din fullständiga ansökan i XQuery och spara den i MarkLogic . Och så borde det vara!
Här är en checklista över vad du ska leta efter i frågespråket för ostrukturerad information:
- Språket för navigeringen
- Datamodell
- Normala uttryck
- Lambda
- Funktioner av hög ordning
- Funktionell doft
- Bra linjebearbetning
- Moduler så att du kan skapa dina egna bibliotek
- Applikationsservern är medveten om:har funktioner som tjänar REST
Du kanske ignorerar detta råd, men i slutändan kan du känna dig frustrerad över Silverlight-utvecklaren. Och vi, killarna som gillar att förnya i databaser, kommer att bli besvikna över att utvecklarna bestämde sig för att gå tillbaka!