Je viens juste de commencer avec des bases de données non relationnelles, et j'essaie toujours de comprendre ce que serait le meilleur modèle. Et je ne peux parler que pour CouchDB.
Pourtant, j'ai quelques conclusions préliminaires:
Avez-vous proposé des conceptions alternatives qui fonctionnent beaucoup mieux dans le monde non relationnel?
L'orientation de la conception change: La conception du modèle de document (correspondant aux tables de base de données) devient quasiment hors de propos, tandis que tout dépend de la conception des vues (correspondant aux requêtes).
La base de données de documents permute en quelque sorte les complexités: SQL a des données inflexibles et des requêtes flexibles, les bases de données de documents sont l'inverse.
Le modèle CouchDB est une collection de "documents JSON" (essentiellement des tables de hachage imbriquées). Chaque document a un identifiant unique et peut être facilement récupéré par identifiant. Pour toute autre requête, vous écrivez des «vues», qui sont des ensembles nommés de fonctions de mappage / réduction. Les vues renvoient un jeu de résultats sous forme de liste de paires clé / valeur.
L'astuce est que vous n'interrogez pas la base de données dans le sens où vous interrogez une base de données SQL: les résultats de l'exécution des fonctions de vue sont stockés dans un index, et seul l'index peut être interrogé. (Comme "obtenir tout", "obtenir la clé" ou "obtenir la plage de clés".)
L'analogie la plus proche dans le monde SQL serait si vous ne pouviez interroger la base de données qu'à l'aide de procédures stockées - chaque requête que vous souhaitez prendre en charge doit être prédéfinie.
La conception des documents est extrêmement flexible. Je n'ai trouvé que deux contraintes:
- Conservez les données associées ensemble dans le même document, car il n'y a rien de correspondant à une jointure.
- Ne rendez pas les documents si volumineux qu'ils sont mis à jour trop fréquemment (comme mettre toutes les ventes de l'entreprise pour l'année dans le même document), car chaque mise à jour de document déclenche une réindexation.
Mais tout dépend de la conception des vues.
Les conceptions alternatives que j'ai trouvées qui fonctionnent mieux avec CouchDB qu'avec n'importe quelle base de données SQL sont au niveau du système plutôt qu'au niveau du stockage. Si vous avez des données et que vous souhaitez les diffuser sur une page Web, la complexité de l'ensemble du système est réduite d'au moins 50%:
- pas de conception de tables de base de données (problème mineur)
- pas de couche intermédiaire ODBC / JDBC, toutes les requêtes et transactions via http (problème modéré)
- mappage DB-à-objet simple de JSON, ce qui est presque trivial par rapport à la même chose en SQL (important!)
- vous pouvez potentiellement ignorer l'ensemble du serveur d'applications, car vous pouvez concevoir vos documents pour qu'ils soient récupérés directement par le navigateur à l'aide d'AJAX et ajouter un peu de polissage JavaScript avant qu'ils ne s'affichent au format HTML. (ÉNORME!!)
Pour les applications Web normales, les bases de données basées sur des documents / JSON sont une victoire massive, et les inconvénients des requêtes moins flexibles et du code supplémentaire pour la validation des données semblent un petit prix à payer.
Vous êtes-vous cogné la tête contre tout ce qui semble impossible?
Pas encore. Mapper / réduire comme moyen d'interroger une base de données n'est pas familier et nécessite beaucoup plus de réflexion que d'écrire du SQL. Il existe un nombre assez restreint de primitives, donc obtenir les résultats dont vous avez besoin est avant tout une question de créativité dans la façon dont vous spécifiez les clés.
Il existe une limitation en ce que les requêtes ne peuvent pas consulter deux documents ou plus en même temps - pas de jointures ou d'autres types de relations multi-documents, mais rien jusqu'à présent n'a été insurmontable.
À titre d'exemple, les comptages et les sommes sont faciles, mais les moyennes ne peuvent pas être calculées par une vue / requête CouchDB. Correction: retournez la somme et comptez séparément et calculez la moyenne sur le client.
Avez-vous comblé le fossé avec des modèles de conception, par exemple pour traduire de l'un à l'autre?
Je ne suis pas sûr que ce soit faisable. Il s'agit plus d'une refonte complète, comme la traduction d'un programme de style fonctionnel en un style orienté objet. En général, il y a beaucoup moins de types de documents que de tables SQL et plus de données dans chaque document.
Une façon d'y penser est de regarder votre SQL pour les insertions et les requêtes courantes: quelles tables et colonnes sont mises à jour lorsqu'un client passe une commande, par exemple? Et lesquels pour les rapports de ventes mensuels? Cette information devrait probablement figurer dans le même document.
C'est-à-dire: Un document pour la commande, contenant l'ID client et les ID produit, avec des champs répliqués si nécessaire pour simplifier les requêtes. Tout ce qui se trouve dans un document peut être interrogé facilement, tout ce qui nécessite des références croisées entre la commande et le client doit être fait par le client. Donc, si vous voulez un rapport sur les ventes par région, vous devriez probablement mettre un code de région dans la commande.
Faites-vous même des modèles de données explicites maintenant (par exemple en UML)?
Désolé, je n'ai jamais fait beaucoup d'UML avant les DB de document :)
Mais vous avez besoin d'une sorte de modèle indiquant quels champs appartiennent à quels documents et quels types de valeurs ils contiennent. À la fois pour votre propre référence plus tard et pour vous assurer que chaque élément utilisant la base de données connaît les conventions. Étant donné que vous n'obtenez plus d'erreur si vous stockez une date dans un champ de texte, par exemple, et que n'importe qui peut ajouter ou supprimer n'importe quel champ de son choix, vous avez besoin à la fois d'un code de validation et de conventions pour prendre le relais. Surtout si vous travaillez avec des ressources externes.
Vous manquez l'un des principaux services supplémentaires fournis par les SGBDR?
Nan. Mais mon expérience est développeur d'applications Web, nous ne traitons les bases de données que dans la mesure où nous devons :)
Une entreprise pour laquelle je travaillais a créé un produit (une application Web) conçu pour fonctionner sur des bases de données SQL de plusieurs fournisseurs, et les «services supplémentaires» sont si différents d'une base de données à l'autre qu'ils ont dû être implémentés séparément pour chaque base de données. Il nous a donc fallu moins de travail pour déplacer la fonctionnalité hors du SGBDR. Cela s'est même étendu à la recherche de texte intégral.
Donc, quoi que j'abandonne, c'est quelque chose que je n'ai jamais vraiment eu en premier lieu. Évidemment, votre expérience peut différer.
Une mise en garde: ce sur quoi je travaille actuellement, c'est une application Web pour les données financières, les cotations boursières et autres. C'est un très bon match pour un document DB, de mon point de vue, j'obtiens tous les avantages d'un DB (persistance et requêtes) sans aucun tracas.
Mais ces données sont assez indépendantes les unes des autres, il n'y a pas de requêtes relationnelles complexes. Obtenez les dernières citations par ticker, obtenez des citations par ticker et par plage de dates, obtenez des méta-informations sur l'entreprise, c'est à peu près tout. Un autre exemple que j'ai vu était une application de blog, et les blogs ne sont pas non plus caractérisés par des schémas de base de données extrêmement compliqués.
Ce que j'essaie de dire, c'est que toutes les applications réussies des bases de données de documents que je connais ont été avec des données qui n'avaient pas beaucoup d'interrelations au départ: documents (comme dans la recherche Google), articles de blog, articles de presse, données financières .
Je m'attends à ce qu'il y ait des ensembles de données qui correspondent mieux à SQL qu'au modèle de document, donc j'imagine que SQL survivra.
Mais pour ceux d'entre nous qui veulent juste un moyen simple de stocker et de récupérer des données - et je soupçonne que nous sommes nombreux - les bases de données de documents (comme dans CouchDB) sont une aubaine.