IBM pureXML, zastrzeżona baza danych XML zbudowana na mechanizmie relacyjnym (zaprojektowanym dla kalamburów), który oferuje zarówno relacyjne (SQL / XML), jak i niestrukturalne (XQuery) języki zapytań, oraz MarkLogic, baza danych zbudowana na podstawie podstaw w oparciu o nowy paradygmat bazy danych (nazwij go NoSQL, jeśli chcesz), który rozumie niestrukturalne dane i oferuje niestrukturalny język zapytań (XQuery).
Kolejną ważną informacją jest nowy trend wśród dostawców baz danych NoSQL w zakresie implementacji SQL (lub interfejsów podobnych do SQL). Przykładem jest niedawna promocja Cassandry z CQL lub jeszcze bardziej dojrzałymi interfejsami SQL opartymi na Hadoop.
Gdy zderzają się dwa światy
NoSQL o braku SQL . Dla mnie oznacza to przesunięcie nacisku na nierelacyjne alternatywy baz danych, które mogą nawet badać różne interfejsy do bazy danych (i nie dbają o poprawność polityczną). To coś dobrego! Ślepo przyznając się do słabości SQL dla biznesu? Cóż, nawet jeśli SQL jest właściwym wyborem dla twojego produktu, nadal musisz pomyśleć o konsekwencjach i upewnić się, że wszystko jest dobrze wyrównane między dwoma światami. Innymi słowy, oznacza to usunięcie „ślepej” części i zredukowanie „ułomności” do akceptowalnego minimum dla twoich programistów.
Model danych
W relacji masz:
RowSet -> SQL -> RowSet
RowSet to coś takiego:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Opowiem Ci o modelu danych XPath:
XDM -> XPath/XQuery -> XDM
A XDM to coś takiego:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Oba są uproszczone, ale służą celowi).
Charakterystyczną cechą modelu danych dla dokumentu jest to, że drzewa nie są płaskie:
{
"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."
}
}
Dlatego istnieje wiele interpretacji tego, co to może oznaczać:
SELECT comments from PERSON where handle = "dscape"
Do jakiego elementu „komentarza” odnosi się żądanie? Jeśli spojrzysz na SQL / XML, twoje zapytanie będzie wyglądać tak:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Prowadzi to do oczywistego wniosku:drzewa potrzebują sposobu na nawigację. W XML jest to XPath, w JSON może to być JSONSelect, może coś innego. Ale nadal potrzebujesz standardowej metody nawigacji.
To, co czyni to zadanie jeszcze bardziej interesującym, to kontrola wersji i rozwój obwodów. Pomimo tego, że było to ignorowane przez wieki w świecie relacyjnym (z poważnymi konsekwencjami dla biznesu z powodu przestojów w tych zabawnych momentach zmiany stołu). , rzeczywiście nie należy tego ignorować w przypadku dokumentów. Pomyśl o Microsoft Word – ile różnych wersji dokumentów obsługuje? Word 2003, 2005 itd.
Brak schematu, elastyczność, brak struktury:wybierz swoje słowo, ale wszystkie podlegają szybkiej ewolucji formatów danych. W tym zapytaniu zakładamy, że deskryptorem jest ludzkie dziecko, a komentarze, że jestem idiotą, są bezpośrednimi potomkami drzewa. To z pewnością się zmieni. A SQL nie obsługuje wersjonowania dokumentów, więc będziesz musiał go rozszerzyć, aby działał.
Rzeczywisty język zapytań dla danych nieustrukturyzowanych musi uwzględniać wersję. W XQuery możemy wyrazić to zapytanie w taki sposób:
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
Frankenquery, na przykład
Ktoś kiedyś wspomniał o mnie (mówiąc o SQL/XML) jako te Frankenquery. Termin do tej pory utkwił mi w głowie. Przyjrzyjmy się tej analogii nieco dalej i poszukajmy miejsc, w których łączą się części organiczne i śruby.
Przedstawmy dwie listy zakupów, jedną dla Joe i jedną dla Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Teraz z moim „wyimaginowanym” rozszerzeniem SQL / JSON, robię:
SELECT apples
FROM LISTS
Co zwraca? Pamiętaj, RowSet wchodzi, RowSet wychodzi?
2, 5
---
6
Tak więc, nawet jeśli wyraźnie zażądasz listy liczb jabłek, otrzymasz dwa zestawy wierszy zamiast trzech, a jeden z zestawów wierszy będzie miał listę liczb. Jeśli zamiast tego zdecydujesz się zwrócić trzy rzeczy, otrzymasz dwa zestawy RowSet i trzy zestawy RowSet. Nie jestem matematykiem, ale to nie brzmi dobrze.
Po raz kolejny nie stanowi to problemu, jeśli użyjesz czegoś, co może poradzić sobie z nieustrukturyzowanymi informacjami. Nie masz tego problemu w javascript i oczywiście nie będzie go w XQuery. Zarówno w javascript, jak i w XQuery wszystko jest organiczne.
Wniosek:oszałamiające języki dla nieustrukturyzowanych danych, jednorożców i wróżek!
Chociaż XQuery jest doskonałym językiem dla nieustrukturyzowanych informacji, mój punkt widzenia nie chroni jego wykorzystania. Punktem, który staram się podkreślić, jest potrzeba prawdziwego języka dla nieustrukturyzowanych danych, bez względu na to, jak (czytaj:programiści) go wybierzesz.
Ale proszę Was (deweloperów), abyście nie wycofywali „słabego SQL”. Ona odeszła, a ty masz nową gorącą randkę o nazwie NoSQL. Po prostu daj mu trochę czasu, a wyrośnie na tobie. Bardzo fajnie jest też pisać kod JavaScript, który działa w bazach danych:nie pozwól, by ci go odebrali.
SQL dla danych nieustrukturyzowanych nie powiedzie się. Wtedy PL-SQL dla danych nieustrukturyzowanych zawiedzie. Więc jeśli dostawca nalega na to, czego potrzebujesz, nie akceptuj niczego innego niż pełny język programowania:możesz napisać całą aplikację w javascript i zapisać ją w CouchApp lub możesz napisać całą aplikację w XQuery i zapisać ją w MarkLogic . I tak powinno być!
Oto lista kontrolna tego, czego należy szukać w języku zapytań w przypadku nieustrukturyzowanych informacji:
- Język nawigacji
- Model danych
- Wyrażenia normalne
- Lambda
- Funkcje wysokiego rzędu
- Zapach funkcjonalny
- Dobre przetwarzanie linii
- Moduły, dzięki którym możesz tworzyć własne biblioteki
- Serwer aplikacji jest świadomy:ma funkcje obsługujące REST
Możesz zignorować tę radę, ale w końcu możesz czuć się sfrustrowany deweloperem Silverlight. A my, ludzie, którzy lubią wprowadzać innowacje w bazach danych, będziemy rozczarowani, że programiści postanowili wrócić!
