IBM pureXML, proprietární databáze XML postavená na relačním mechanismu (navrženém pro slovní hříčky), který nabízí jak relační (SQL/XML), tak nestrukturované (XQuery) dotazovací jazyky, a MarkLogic, databáze vytvořená z scratch na základě nového databázového paradigmatu (chcete-li ho nazývat NoSQL), který rozumí nestrukturovaným datům a nabízí nestrukturovaný dotazovací jazyk ( XQuery ).
Další důležitou informací je nový trend mezi poskytovateli NoSQL databází pro implementaci SQL (nebo SQL podobných rozhraní). Příkladem je nedávná propagace Cassandry s CQL nebo ještě vyspělejšími SQL rozhraními založenými na Hadoop.
Když se střetnou dva světy
NoSQL o No SQL . Pro mě to znamená přesunout důraz na nerelační databázové alternativy, které mohou dokonce zkoumat různá rozhraní k databázi (a nestarají se o politickou korektnost). To je dobrá věc! Slepě přiznat slabost SQL pro podnikání? I když je SQL tou správnou volbou pro váš produkt, stále musíte myslet na důsledky a ujistit se, že jsou věci mezi těmito dvěma světy dobře sladěny. Jinými slovy to znamená odstranit „slepou“ část a snížit „lame“ na přijatelné minimum pro vaše vývojáře.
Datový model
Ve vztahu máte:
RowSet -> SQL -> RowSet
RowSet je něco takového:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Řeknu vám o datovém modelu XPath:
XDM -> XPath/XQuery -> XDM
A XDM je něco takového:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Oba jsou zjednodušené, ale slouží svému účelu) .
Charakteristickým rysem datového modelu pro dokument je, že stromy nejsou ploché:
{
"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."
}
}
Existuje tedy mnoho výkladů toho, co to může znamenat:
SELECT comments from PERSON where handle = "dscape"
Na který prvek „komentáře“ se žádost vztahuje? Pokud se podíváte na SQL / XML, váš dotaz bude vypadat takto:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
To vede k tomuto zřejmému závěru:stromy potřebují způsob, jak se pohybovat. V XML je to XPath, v JSON to může být JSONSelect, možná něco jiného. Ale stále potřebujete standardní metodu navigace na prvním místě.
Co dělá tento úkol ještě zajímavějším, je kontrola verzí a vývoj okruhů. Nehledě na to, že to bylo v relačním světě po věky ignorováno (s vážnými důsledky pro podnikání kvůli prostojům v těchto vtipných okamžicích změn tabulek). , to opravdu nelze u dokumentů ignorovat. Přemýšlejte o aplikaci Microsoft Word – kolik různých verzí dokumentů podporuje? Word 2003, 2005 atd.
Žádné schéma, flexibilita, nestrukturované:zvolte si slovo, ale všechny podléhají rychlému vývoji datových formátů. V tomto dotazu předpokládáme, že deskriptor je lidské dítě a že komentáře, že jsem idiot, jsou přímým potomkem stromu. To se určitě změní. A SQL nepodporuje verzování dokumentů, takže ho budete muset rozšířit, aby fungoval.
Skutečný dotazovací jazyk pro nestrukturovaná data musí brát v úvahu verzi. V XQuery můžeme tento dotaz vyjádřit nějak takto:
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
Například Frankenqueries
Někdo mě jednou zmínil (mluvím o SQL / XML) jako o těchto Frankenqueries. Ten termín mi utkvěl v hlavě doteď. Podívejme se na tuto analogii trochu dále a hledejme místa, kde se organické části a šrouby spojují.
Pojďme si představit dva nákupní seznamy, jeden pro Joea a jeden pro Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Nyní s mým „imaginárním“ rozšířením SQL / JSON:
SELECT apples
FROM LISTS
co to vrací? Pamatujete si, že sada RowSet jde dovnitř, sada RowSet odejde?
2, 5
---
6
I když tedy výslovně požadujete seznam čísel jablek, dostanete dvě sady řádků místo tří a jedna ze sad řádků bude mít seznam čísel. Pokud se místo toho rozhodnete vrátit tři věci, získáte dvě sady RowSet a tři sady RowSet. Nejsem matematik, ale to nezní dobře.
Opět není problém, pokud používáte něco, co by se mohlo zabývat nestrukturovanými informacemi. Tento problém nemáte v javascriptu a samozřejmě nebude v XQuery. Jak v javascriptu, tak v XQuery je vše organické.
Závěr:úžasné jazyky pro nestrukturovaná data, jednorožce a pixie prach!
Přestože XQuery je vynikající jazyk pro nestrukturované informace, můj názor zde nechrání jeho použití. Pointa, kterou se snažím zdůraznit, je potřeba skutečného jazyka pro nestrukturovaná data, bez ohledu na to, jak si ho (čti vývojáři) vyberete.
Ale žádám vás (vývojáře), abyste nebrali zpět „lame SQL“. Odešla a vy máte nové horké rande s názvem NoSQL. Dejte tomu trochu času a ono vám to vyroste. Je také velmi zábavné psát kód JavaScript, který funguje v databázích:nenechte je, aby vám ho vzali.
SQL pro nestrukturovaná data selže. Pak PL-SQL pro nestrukturovaná data selže. Pokud tedy prodejce trvá na tom, co potřebujete, neakceptujte nic menšího než úplný programovací jazyk:můžete napsat svou kompletní aplikaci v javascriptu a uložit ji v CouchApp, nebo můžete celou aplikaci napsat v XQuery a uložit ji v MarkLogic. . A tak by to mělo být!
Zde je kontrolní seznam toho, co hledat v dotazovacím jazyce pro nestrukturované informace:
- Jazyk navigace
- Datový model
- Normální výrazy
- Lambda
- Funkce vyššího řádu
- Funkční vůně
- Dobré zpracování řádku
- Moduly, abyste mohli vytvářet své vlastní knihovny
- Aplikační server si je vědom:má funkce, které slouží REST
Můžete tuto radu ignorovat, ale nakonec se můžete cítit frustrovaní vývojářem Silverlight. A my, kluci, kteří rádi inovují v databázích, budeme zklamáni, že se vývojáři rozhodli vrátit!