IBM pureXML, un database XML proprietario costruito su un meccanismo relazionale (progettato per giochi di parole) che offre linguaggi di query sia relazionali (SQL/XML) che non strutturati (XQuery), e MarkLogic, un database creato da scratch sulla base di un nuovo paradigma di database (chiamalo NoSQL se vuoi) che comprende i dati non strutturati e offre un linguaggio di query non strutturato ( XQuery ).
Un'altra informazione importante è la nuova tendenza tra i provider di database NoSQL per l'implementazione di SQL (o interfacce simili a SQL). Un esempio è la recente promozione di Cassandra con CQL o interfacce SQL ancora più mature basate su Hadoop.
Quando due mondi si scontrano
NoSQL su No SQL . Per me, questo significa spostare l'enfasi su alternative di database non relazionali, che possono anche esplorare diverse interfacce del database (e non si preoccupano della correttezza politica). Questa è una buona cosa! Ammettere ciecamente la debolezza di SQL per il business? Bene, anche se SQL è la scelta giusta per il tuo prodotto, devi comunque pensare alle conseguenze e assicurarti che le cose siano ben allineate tra i due mondi. In altre parole, significa rimuovere la parte "cieca" e ridurre lo "zoppo" a un minimo accettabile per i tuoi sviluppatori.
Modello di dati
In relazionale hai:
RowSet -> SQL -> RowSet
RowSet è qualcosa del genere:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Ti parlerò del modello di dati XPath:
XDM -> XPath/XQuery -> XDM
E XDM è qualcosa del genere:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Entrambi sono semplificati, ma servono a uno scopo) .
Una caratteristica distintiva del modello dati per il documento è che gli alberi non sono piatti:
{
"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."
}
}
Pertanto, ci sono molte interpretazioni di ciò che questo può significare:
SELECT comments from PERSON where handle = "dscape"
A quale elemento del “commento” si riferisce la richiesta? Se guardi SQL / XML, la tua query sarà simile a questa:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Questo porta a questa ovvia conclusione:gli alberi hanno bisogno di un modo per navigare. In XML è XPath, in JSON potrebbe essere JSONSelect, forse qualcos'altro. Ma in primo luogo hai ancora bisogno del metodo di navigazione standard.
Ciò che rende questo compito ancora più interessante è il controllo della versione e lo sviluppo del circuito. Nonostante questo sia stato ignorato per anni nel mondo relazionale (con gravi conseguenze per il business dovute ai tempi morti in questi divertenti momenti di cambio tavola). , questo in effetti non deve essere ignorato per i documenti. Pensa a Microsoft Word:quante diverse versioni di documenti supportano? Parola 2003, 2005, ecc.
Nessuno schema, flessibilità, destrutturato:scegli la tua parola, ma sono tutti soggetti alla rapida evoluzione dei formati dei dati. In questa query, assumiamo che il descrittore sia un bambino umano e che i commenti che sono un idiota siano un discendente diretto dell'albero. Questo cambierà sicuramente. E SQL non supporta il controllo delle versioni dei documenti, quindi dovrai estenderlo per farlo funzionare.
Il vero linguaggio di query per i dati non strutturati deve tenere conto della versione. In XQuery possiamo esprimere questa query come qualcosa del genere:
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, per esempio
Qualcuno una volta mi ha menzionato (parlando di SQL / XML) come questi Frankenquery. Il termine mi è rimasto in testa finora. Diamo un'occhiata un po' più lontano a questa analogia e cerchiamo i punti in cui parti organiche e bulloni si uniscono.
Presentiamo due liste della spesa, una per Joe e una per Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Ora con la mia estensione SQL / JSON "immaginaria", faccio:
SELECT apples
FROM LISTS
Cosa restituisce? Ricordi, RowSet entra, RowSet esce?
2, 5
---
6
Pertanto, anche se richiedi esplicitamente un elenco di numeri di mela, ottieni due serie di righe anziché tre e una delle serie di righe avrà un elenco di numeri. Se invece scegli di restituire tre cose, otterrai due set RowSet e tre set RowSet. Non sono un matematico, ma non suona bene.
Ancora una volta, non è un problema se utilizzi qualcosa che potrebbe gestire informazioni non strutturate. Non hai questo problema in javascript e, naturalmente, non sarà in XQuery. Sia in javascript che in XQuery è tutto organico.
Conclusione:linguaggi straordinari per dati non strutturati, unicorni e polvere di folletti!
Sebbene XQuery sia un eccellente linguaggio per informazioni non strutturate, il mio punto di vista qui non ne protegge l'uso. Il punto che sto cercando di sottolineare è la necessità di un vero linguaggio per i dati non strutturati, indipendentemente da come (leggi:sviluppatori) lo scegli.
Ma chiedo a voi (gli sviluppatori) di non riprendervi lo "zoppo SQL". Se n'è andata e tu hai un nuovo appuntamento caldo chiamato NoSQL. Dagli un po' di tempo e crescerà su di te. È anche molto divertente scrivere codice JavaScript che funzioni nei database:non lasciare che te lo portino via.
SQL per dati non strutturati avrà esito negativo. Quindi PL-SQL per dati non strutturati fallirà. Quindi se il venditore insiste su ciò di cui hai bisogno, non accettare niente di meno che un linguaggio di programmazione completo:puoi scrivere la tua applicazione completa in javascript e salvarla in CouchApp, oppure puoi scrivere la tua applicazione completa in XQuery e salvarla in MarkLogic . E così dovrebbe essere!
Ecco un elenco di controllo di cosa cercare nel linguaggio di query per informazioni non strutturate:
- La lingua di navigazione
- Modello di dati
- Espressioni normali
- Lambda
- Funzioni di alto livello
- Fragranza funzionale
- Buona elaborazione della linea
- Moduli per creare le tue librerie
- Il server delle applicazioni è a conoscenza:ha funzioni che servono REST
Potresti ignorare questo consiglio, ma alla fine potresti sentirti frustrato dallo sviluppatore Silverlight. E noi, i ragazzi a cui piace innovare nei database, saremo delusi dal fatto che gli sviluppatori abbiano deciso di tornare indietro!
