IBM pureXML, собствена XML база данни, изградена върху релационен механизъм (предназначен за каламбури), който предлага както релационни ( SQL / XML ), така и неструктурирани ( XQuery ) езици за заявки, и MarkLogic, база данни, изградена от scratch на базата на нова парадигма на базата данни (наречете я NoSQL, ако искате), която разбира неструктурирани данни и предлага неструктуриран език за заявки ( XQuery ).
Друга важна информация е новата тенденция сред доставчиците на бази данни NoSQL за внедряване на SQL (или SQL-подобни интерфейси). Пример е скорошното популяризиране на Cassandra с CQL или дори по-зрели SQL интерфейси, базирани на Hadoop.
Когато два свята се сблъскат
NoSQL относно Без SQL. За мен това означава изместване на акцента към алтернативи на нерелационни бази данни, които дори могат да изследват различни интерфейси към базата данни (и не се интересуват от политическа коректност). Това е хубаво нещо! Признавайки сляпо слабостта на SQL за бизнеса? Е, дори SQL да е правилният избор за вашия продукт, все пак трябва да мислите за последствията и да се уверите, че нещата са добре подравнени между двата свята. С други думи, това означава премахване на „сляпата“ част и намаляване на „куцото“ до приемлив минимум за вашите разработчици.
Модел на данни
В релационните имате:
RowSet -> SQL -> RowSet
RowSet е нещо подобно:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Ще ви разкажа за модела на данни XPath:
XDM -> XPath/XQuery -> XDM
А XDM е нещо подобно:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(И двете са опростени, но служат за цел) .
Отличителна черта на модела на данни за документа е, че дърветата не са плоски:
{
"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."
}
}
По този начин има много интерпретации на това какво може да означава това:
SELECT comments from PERSON where handle = "dscape"
За кой елемент на „коментар“ се отнася искането? Ако погледнете SQL / XML, вашата заявка ще изглежда така:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Това води до това очевидно заключение:дърветата се нуждаят от начин за навигация. В XML това е XPath, в JSON може да е JSONSelect, може би нещо друго. Но на първо място все още се нуждаете от стандартния метод за навигация.
Това, което прави тази задача още по-интересна, е контролът на версиите и разработването на схеми. Въпреки факта, че това е било игнорирано от векове в релационния свят (със сериозни последици за бизнеса поради прекъсване в тези смешни моменти на промени в таблицата). , това наистина не бива да се пренебрегва за документи. Помислете за Microsoft Word – колко различни версии на документи поддържат? Word 2003, 2005 и др.
Без схема, гъвкавост, неструктуриране:изберете вашата дума, но всички те са обект на бързото развитие на форматите на данни. В тази заявка приемаме, че дескрипторът е човешко дете и че коментарите, че съм идиот, са пряк потомък на дървото. Това със сигурност ще се промени. И SQL не поддържа версията на документи, така че ще трябва да го разширите, за да работи.
Истинският език за заявки за неструктурирани данни трябва да вземе предвид версията. В XQuery можем да изразим тази заявка като нещо подобно:
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, например
Някой веднъж ме спомена (говорейки за SQL/XML) като тези Frankenqueries. Досега терминът ми се е забил в главатата Нека разгледаме малко по-нататък тази аналогия и да потърсим места, където органичните части и болтовете се събират.
Нека представим два списъка за пазаруване, един за Джо и един за Мери.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Сега с моето „въображаемо“ разширение SQL / JSON правя:
SELECT apples
FROM LISTS
Какво връща? Помните ли, RowSet влиза, RowSet излиза?
2, 5
---
6
По този начин, дори ако изрично поискате списък с числа на ябълка, получавате два набора от редове вместо три и един от наборите от редове ще има списък с числа. Ако вместо това изберете да върнете три неща, ще получите два набора RowSet и три набора RowSet. Не съм математик, но това не звучи добре.
Още веднъж, не е проблем, ако използвате нещо, което може да се справи с неструктурирана информация. Нямате този проблем в javascript и разбира се, няма да е в XQuery. И в javascript, и в XQuery всичко е органично.
Заключение:зашеметяващи езици за неструктурирани данни, еднорози и пикси прах!
Въпреки че XQuery е отличен език за неструктурирана информация, моята гледна точка тук не защитава нейното използване. Въпросът, който се опитвам да подчертая, е необходимостта от реален език за неструктурирани данни, без значение как вие (четете:разработчиците) го изберете.
Но ви моля (разработчиците) да не връщате обратно „куция SQL“. Тя си отиде, а вие имате нова гореща среща, наречена NoSQL. Просто му дайте малко време и то ще ви расте. Също така е много забавно да пишете JavaScript код, който работи в бази данни:не им позволявайте да ви го отнемат.
SQL за неструктурирани данни ще се провали. Тогава PL-SQL за неструктурирани данни ще се провали. Така че, ако доставчикът настоява за това, от което се нуждаете, не приемайте нищо по-малко от пълен език за програмиране:можете да напишете цялото си приложение на javascript и да го запишете в CouchApp, или можете да напишете цялото си приложение в XQuery и да го запишете в MarkLogic . И така трябва да бъде!
Ето контролен списък какво да търсите в езика на заявките за неструктурирана информация:
- Езикът на навигацията
- Модел на данни
- Нормални изрази
- Ламбда
- Функции от висок порядък
- Функционален аромат
- Добра обработка на линията
- Модули, за да можете да създавате свои собствени библиотеки
- Сървърът на приложения е наясно:има функции, които обслужват REST
Може да пренебрегнете този съвет, но в крайна сметка може да се почувствате разочаровани от разработчика на Silverlight. И ние, момчетата, които обичат да правят иновации в базите данни, ще бъдем разочаровани, че разработчиците решиха да се върнат!
