IBM pureXML, une base de données XML propriétaire construite sur un mécanisme relationnel (conçu pour les jeux de mots) qui offre à la fois des langages de requête relationnels ( SQL / XML ) et non structurés ( XQuery ), et MarkLogic, une base de données construite à partir de scratch sur la base d'un nouveau paradigme de base de données (appelez-le NoSQL si vous voulez) qui comprend les données non structurées et offre un langage de requête non structuré ( XQuery ).
Une autre information importante est la nouvelle tendance parmi les fournisseurs de bases de données NoSQL pour la mise en œuvre de SQL (ou d'interfaces de type SQL). Un exemple est la récente promotion de Cassandra avec CQL ou encore des interfaces SQL plus matures basées sur Hadoop.
Quand deux mondes se rencontrent
NoSQL à propos de No SQL . Pour moi, cela signifie mettre l'accent sur des alternatives de base de données non relationnelles, qui peuvent même explorer différentes interfaces avec la base de données (et ne se soucient pas du politiquement correct). C'est une bonne chose! Admettre aveuglément la faiblesse de SQL pour les entreprises ? Eh bien, même si SQL est le bon choix pour votre produit, vous devez toujours réfléchir aux conséquences et vous assurer que les choses sont bien alignées entre les deux mondes. En d'autres termes, cela signifie supprimer la partie "aveugle" et réduire le "boiteux" à un minimum acceptable pour vos développeurs.
Modèle de données
En relationnel vous avez :
RowSet -> SQL -> RowSet
RowSet est quelque chose comme ça :
RowSet -> Item+
Article -> INT | VARCHAR n | ...
Je vais vous parler du modèle de données XPath :
XDM -> XPath/XQuery -> XDM
Et XDM est quelque chose comme ça :
XDM -> Article+
Item -> AtomicType | Arbre
AtomicType -> entier | chaîne | ...
...
(Les deux sont simplifiés, mais ont un but) .
Une caractéristique distinctive du modèle de données pour le document est que les arbres ne sont pas plats :
{
"namespace":"personne-2.0",
"comments":"Ce type m'a demandé un autocollant de dinosaure. Quel dingue !",
"personne":{/code>
"handle":"dscape",
"comments":"Veuillez ne pas envoyer de courrier non sollicité."
}
}
Ainsi, il existe de nombreuses interprétations de ce que cela peut signifier :
SELECT commentaires de PERSON où handle ="dscape"
À quel élément de « commentaire » la demande fait-elle référence ? Si vous regardez SQL/XML, votre requête ressemblera à ceci :
SELECT XMLQuery('$personne/commentaires')
DE LA PERSONNE
WHERE XMLExists('$person/person/handle')
Cela conduit à cette conclusion évidente :les arbres ont besoin d'un moyen de naviguer. En XML, c'est XPath, en JSON, ce pourrait être JSONSelect, peut-être autre chose. Mais vous avez toujours besoin de la méthode de navigation standard en premier lieu.
Ce qui rend cette tâche encore plus intéressante, c'est le contrôle de version et le développement de circuits. Malgré le fait que cela a été ignoré pendant des lustres dans le monde relationnel (avec de graves conséquences pour les affaires en raison des temps d'arrêt dans ces drôles de moments de changements de table). , ceci n'est en effet pas à négliger pour les documents. Pensez à Microsoft Word - combien de versions différentes de documents prennent-ils en charge ? Word 2003, 2005, etc.
Pas de schéma, flexibilité, non structuré :choisissez votre mot, mais ils sont tous soumis à l'évolution rapide des formats de données. Dans cette requête, nous supposons que le descripteur est un enfant humain et que les commentaires disant que je suis un idiot sont un descendant direct de l'arbre. Cela va certainement changer. Et SQL ne prend pas en charge la gestion des versions des documents, vous devrez donc l'étendre pour que cela fonctionne.
Le vrai langage de requête pour les données non structurées doit tenir compte de la version. Dans XQuery, nous pouvons exprimer cette requête comme quelque chose comme ça :
déclarer l'espace de noms p ="personne-2.0";
for $person in collection('person')
laissez $comments-on-person :=$person/p:comments
où $person/p:handle ="dscape"
return $comments-on-person
Frankenqueries, par exemple
Quelqu'un m'a un jour mentionné (parlant de SQL/XML) comme ces Frankenqueries. Le terme m'est resté en tête jusqu'à présent. Examinons un peu plus loin cette analogie et recherchons les endroits où les pièces organiques et les boulons se rejoignent.
Présentons deux listes de courses, une pour Joe et une pour Mary.
marys-shopping.json
{"fruit":{/code>
"pommes":2
}, "pommes":5 }
joes-shopping.json
{"fruit":{/code>
"pommes":6,
"oranges":1
} }
Maintenant avec mon extension SQL/JSON « imaginaire », je fais :
SELECT pommes
DES LISTES
Que retourne-t-il ? Rappelez-vous, RowSet entre, RowSet sort ?
2, 5
---
6
Ainsi, même si vous demandez explicitement une liste de numéros de pomme, vous obtenez deux ensembles de lignes au lieu de trois, et l'un des ensembles de lignes aura une liste de nombres. Si vous choisissez de renvoyer trois éléments à la place, vous obtiendrez deux ensembles RowSet et trois ensembles RowSet. Je ne suis pas mathématicien, mais cela ne sonne pas bien.
Encore une fois, ce n'est pas un problème si vous utilisez quelque chose qui pourrait traiter des informations non structurées. Vous n'avez pas ce problème en javascript et bien sûr, ce ne sera pas dans XQuery. Tant en javascript que dans XQuery, tout est organique.
Conclusion :des langages époustouflants pour les données non structurées, les licornes et la poussière de lutin !
Bien que XQuery soit un excellent langage pour les informations non structurées, mon point de vue ici ne protège pas son utilisation. Le point sur lequel j'essaie de mettre l'accent est la nécessité d'un vrai langage pour les données non structurées, peu importe comment vous (lire :les développeurs) le choisissez.
Mais je vous demande (aux développeurs) de ne pas reprendre le « SQL boiteux ». Elle est partie et vous avez un nouveau rendez-vous chaud appelé NoSQL. Donnez-lui juste un peu de temps et il grandira sur vous. C'est aussi très amusant d'écrire du code JavaScript qui fonctionne dans les bases de données :ne les laissez pas vous le prendre.
SQL pour les données non structurées échouera. Ensuite, PL-SQL pour les données non structurées échouera. Donc, si le fournisseur insiste sur ce dont vous avez besoin, n'acceptez rien de moins qu'un langage de programmation complet :vous pouvez écrire votre application complète en javascript et l'enregistrer dans CouchApp, ou vous pouvez écrire votre application complète dans XQuery et l'enregistrer dans MarkLogic. . Et il devrait en être ainsi !
Voici une liste de contrôle de ce qu'il faut rechercher dans le langage de requête pour les informations non structurées :
- La langue de la navigation
- Modèle de données
- Expressions normales
- Lambda
- Fonctions d'ordre supérieur
- Parfum fonctionnel
- Bon traitement de ligne
- Des modules pour créer vos propres bibliothèques
- Le serveur d'application est conscient :possède des fonctions qui servent REST
Vous pouvez ignorer ce conseil, mais à la fin, vous pouvez vous sentir frustré par le développeur Silverlight. Et nous, les gars qui aimons innover dans les bases de données, serons déçus que les développeurs aient décidé de revenir en arrière !
