IBM pureXML, een eigen XML-database gebouwd op een relationeel mechanisme (ontworpen voor woordspelingen) dat zowel relationele ( SQL / XML ) als ongestructureerde ( XQuery ) querytalen biedt, en MarkLogic, een database die is opgebouwd uit scratch op basis van een nieuw databaseparadigma (noem het NoSQL als je wilt) dat ongestructureerde gegevens begrijpt en ongestructureerde zoektaal biedt ( XQuery ).
Een andere belangrijke informatie is de nieuwe trend onder NoSQL-databaseproviders voor het implementeren van SQL (of SQL-achtige interfaces). Een voorbeeld is de recente promotie van Cassandra met CQL of zelfs meer volwassen SQL-interfaces op basis van Hadoop.
Als twee werelden botsen
NoSQL over Geen SQL . Voor mij betekent dit dat de nadruk moet worden verlegd naar niet-relationele database-alternatieven, die zelfs verschillende interfaces met de database kunnen verkennen (en zich niets aantrekken van politieke correctheid). Dit is iets goeds! Blindelings de zwakte van SQL voor bedrijven toegeven? Welnu, zelfs als SQL de juiste keuze is voor uw product, moet u nog steeds nadenken over de gevolgen en ervoor zorgen dat de zaken goed op elkaar zijn afgestemd tussen de twee werelden. Met andere woorden, het betekent het verwijderen van het "blinde" gedeelte en het verminderen van "lame" tot een acceptabel minimum voor uw ontwikkelaars.
Gegevensmodel
In relationeel heb je:
RowSet -> SQL -> RowSet
RowSet is zoiets:
RowSet -> Item+
Item -> INT | VARCHAR n | ...
Ik zal je vertellen over het XPath-gegevensmodel:
XDM -> XPath/XQuery -> XDM
En XDM is zoiets:
XDM -> Item+
Item -> AtomicType | Tree
AtomicType -> integer | string | ...
...
(Beide zijn vereenvoudigd, maar dienen een doel) .
Een onderscheidend kenmerk van het datamodel voor het document is dat de bomen niet plat zijn:
{
"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."
}
}
Er zijn dus veel interpretaties van wat dit kan betekenen:
SELECT comments from PERSON where handle = "dscape"
Naar welk element van "opmerking" verwijst het verzoek? Als u naar SQL / XML kijkt, ziet uw query er als volgt uit:
SELECT XMLQuery('$person/comments')
FROM PERSON
WHERE XMLExists('$person/person/handle')
Dit leidt tot deze voor de hand liggende conclusie:bomen hebben een manier nodig om te navigeren. In XML is het XPath, in JSON kan het JSONSelect zijn, misschien iets anders. Maar je hebt in de eerste plaats nog steeds de standaard navigatiemethode nodig.
Wat deze taak nog interessanter maakt, is versiebeheer en circuitontwikkeling. Ondanks dat dit in de relationele wereld al eeuwen wordt genegeerd (met ernstige gevolgen voor de business door downtime op deze grappige momenten van tafelwisselingen). , dit is inderdaad niet te negeren voor documenten. Denk aan Microsoft Word - hoeveel verschillende versies van documenten ondersteunen ze? Word 2003, 2005, enz.
Geen schema, flexibiliteit, ongestructureerd:kies je woord, maar ze zijn allemaal onderhevig aan de snelle evolutie van dataformaten. In deze vraag gaan we ervan uit dat de descriptor een mensenkind is en dat de opmerkingen dat ik een idioot ben een directe afstammeling zijn van de boom. Dit zal zeker veranderen. En SQL ondersteunt geen versiebeheer van documenten, dus je zult het moeten uitbreiden om het te laten werken.
De echte zoektaal voor ongestructureerde gegevens moet rekening houden met de versie. In XQuery kunnen we deze vraag als volgt uitdrukken:
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
Openvragen, bijvoorbeeld
Iemand noemde mij ooit (over SQL / XML gesproken) als deze Frankenquery's. De term is me tot nu toe blijven hangen. Laten we wat verder kijken naar deze analogie en op zoek gaan naar plaatsen waar organische onderdelen en bouten samenkomen.
Laten we twee boodschappenlijstjes presenteren, een voor Joe en een voor Mary.
marys-shopping.json
{"fruit": {
"apples": 2
}, "apples": 5 }
joes-shopping.json
{"fruit": {
"apples": 6,
"oranges": 1
} }
Nu met mijn "denkbeeldige" SQL / JSON-extensie, doe ik:
SELECT apples
FROM LISTS
Wat geeft het terug? Weet je nog, RowSet gaat erin, RowSet gaat uit?
2, 5
---
6
Dus zelfs als u expliciet om een lijst met appelnummers vraagt, krijgt u twee sets rijen in plaats van drie, en een van de sets rijen heeft een lijst met nummers. Als u ervoor kiest om in plaats daarvan drie dingen te retourneren, krijgt u twee RowSet-sets en drie RowSet-sets. Ik ben geen wiskundige, maar dat klinkt niet goed.
Nogmaals, het is geen probleem als je iets gebruikt dat mogelijk te maken heeft met ongestructureerde informatie. Je hebt dit probleem niet in javascript en natuurlijk ook niet in XQuery. Zowel in javascript als in XQuery is het allemaal organisch.
Conclusie:verbluffende talen voor ongestructureerde gegevens, eenhoorns en elfenstof!
Hoewel XQuery een uitstekende taal is voor ongestructureerde informatie, beschermt mijn standpunt hier het gebruik ervan niet. Het punt dat ik probeer te benadrukken, is de noodzaak van een echte taal voor ongestructureerde gegevens, ongeacht hoe u (lees:ontwikkelaars) deze ook kiest.
Maar ik vraag u (de ontwikkelaars) om de "lame SQL" niet terug te nemen. Ze is weg en je hebt een nieuwe hete date genaamd NoSQL. Geef het gewoon wat tijd en het zal op je groeien. Het is ook erg leuk om JavaScript-code te schrijven die werkt in databases:laat ze het je niet afnemen.
SQL voor ongestructureerde gegevens zal mislukken. Dan zal PL-SQL voor ongestructureerde data mislukken. Dus als de leverancier aandringt op wat u nodig hebt, accepteer dan niets minder dan een volledige programmeertaal:u kunt uw volledige toepassing in javascript schrijven en opslaan in CouchApp, of u kunt uw volledige toepassing in XQuery schrijven en opslaan in MarkLogic . En zo zou het moeten zijn!
Hier is een checklist van waar u naar moet zoeken in de zoektaal voor ongestructureerde informatie:
- De taal van de navigatie
- Gegevensmodel
- Normale uitdrukkingen
- Lambda
- Functies van hoge orde
- Functionele geur
- Goede regelverwerking
- Modules zodat u uw eigen bibliotheken kunt maken
- De applicatieserver is op de hoogte:heeft functies die REST dienen
U kunt dit advies negeren, maar uiteindelijk kunt u zich gefrustreerd voelen over de Silverlight-ontwikkelaar. En wij, de jongens die graag innoveren in databases, zullen teleurgesteld zijn dat de ontwikkelaars besloten terug te gaan!