J'ai seulement commencé avec les non-relationnelles DBs, et je suis encore à essayer d'envelopper ma tête autour de lui et comprendre ce que le meilleur modèle serait. Et je ne peux parler que pour CouchDB.
Encore, j'ai quelques conclusions préliminaires:
Avez-vous venir avec des designs alternatifs qui fonctionnent beaucoup mieux dans le non-monde relationnel?
La conception focus: déplacements de La conception du modèle de document (correspondant à DB tables) devient presque hors de propos, alors que tout dépend de la conception de la vue (correspondant à des requêtes).
Le document DB sorte de swaps de la complexité: SQL a inflexible de données et des requêtes flexibles, document DBs sont dans l'autre sens.
Le CouchDB est un modèle de la collection des "documents JSON" (en gros, imbriqués les tables de hachage). Chaque document possède un IDENTIFIANT unique, et peut être trivialement récupérées par ID. Pour toute autre question, vous écrivez "points de vue", qui sont nommées ensembles de map/reduce fonctions. Le point de vue de retourner un résultat comme une liste de paires clé/valeur.
Le truc, c'est que vous n'avez pas de requête de la base de données dans le sens d'une requête sur une base de données SQL: Les résultats de l'exécution de la fonction d'affichage sont stockées dans un index, et que l'index peut être interrogé. (Comme "tout obtenir", "clé" ou "obtenir les clés de la gamme".)
L'analogie la plus proche dans le monde SQL serait si vous pouviez seulement requête de la DB à l'aide de procédures stockées - chaque requête que vous souhaitez à l'appui doivent être prédéfinies.
La conception de ces documents est extrêmement flexible. J'ai trouvé seulement deux contraintes:
- Conserver des données ensemble dans le même document, car il n'en est rien, correspondant à une jointure.
- Ne faites pas les documents de si grands qu'ils sont mis à jour trop souvent (comme mettre toutes les ventes de l'entreprise pour l'année dans le même document), car à chaque mise à jour du document déclenche une ré-indexation.
Mais tout dépend de la conception que de la vue.
L'autre dessins, j'ai trouvé que le travail ordres de grandeur mieux avec CouchDB que n'importe quelle base de données SQL sont au niveau du système plutôt que le niveau de stockage. Si vous avez quelques données et que vous souhaitez les servir à une page web, la complexité de l'ensemble du système est réduite d'au moins 50%:
- pas de concevoir des tables DB (problème mineur)
- pas de ODBC/JDBC couche intermédiaire, toutes les requêtes et transactions sur http (problème modéré)
- simple DB-objet de mappage de JSON, qui est presque négligeable par rapport à la même dans SQL (important!)
- vous pouvez éventuellement passer la totalité de serveur d'applications, que vous pouvez concevoir vos documents peuvent être récupérées directement par le navigateur à l'aide d'AJAX et d'ajouter un peu de JavaScript polissage avant ils sont affichés au format HTML. (ÉNORME!!)
Normal webapps, document/basé sur JSON DBs sont une énorme victoire, et les inconvénients de moins en moins flexibles requêtes et un certain code supplémentaire pour la validation des données semble être un petit prix à payer.
Avez-vous frapper votre tête contre quelque chose qui semble impossible?
Pas encore de. Map/reduce comme un moyen d'interrogation d'une base de données est inconnu, et demande beaucoup plus de réflexion que d'écrire du SQL. Il y a un assez petit nombre de primitives, afin d'obtenir les résultats que vous avez besoin est avant tout une question d'être créatif avec la façon dont vous spécifiez les touches.
Il y a une limitation en ce que les requêtes ne peuvent pas regarder deux ou plusieurs documents en même temps - pas de joints ou d'autres types de multi-document de relations, mais rien n'a été jusqu'ici impossible.
Comme un exemple de limitation, les chiffres et les montants sont faciles, mais les moyennes ne peut pas être calculé par une vue CouchDB/requête. Corrigé: renvoie la somme et le nombre séparément et de calculer la moyenne sur le client.
Avez-vous a comblé l'écart avec n'importe quel des modèles de conception, par exemple, de traduire à partir de l'une à l'autre?
Je ne suis pas sûr que ce soit faisable. C'est plus d'une refonte complète, comme la traduction d'un style fonctionnel programme pour un style orienté objets. En général, il ya beaucoup moins de types de documents qu'il y a des tables SQL et plus de données dans chaque document.
Une façon de penser, il est de regarder votre SQL pour les insertions et les requêtes communes: les tables et les colonnes sont mis à jour lorsqu'un client passe une commande, par exemple? Et ceux qui pour des rapports de ventes mensuels? Cette info devrait probablement aller dans le même document.
Que est: Un document pour l'Ordre, contenant l'ID du client et de l'Id de produit, avec répliqué de champs que nécessaire de simplifier les requêtes. Quoi que ce soit dans un document peut être consulté facilement, chose qui nécessite un croisement entre les dire de l'Ordre et le Client doit être effectué 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 l'ordre.
Avez-vous même n'explicite des modèles de données du tout (par exemple, en UML)?
Désolé, n'a jamais fait beaucoup UML avant de document DBs :)
Mais vous besoin d'une sorte de modèle de dire quels sont les champs appartiennent à qui les documents et quels types de valeurs qu'ils contiennent. À la fois pour votre propre référence, plus tard, et assurez-vous que everybod à l'aide de la DB connaît les conventions. Puisque vous n'avez plus obtenez un message d'erreur si vous stockez une date dans un champ de texte, par exemple, et n'importe qui peut ajouter ou supprimer n'importe quel champ qu'ils en ont envie, vous avez besoin d'un code de validation et de conventions de prendre le relais. Surtout si vous travaillez avec des ressources externes.
Ne vous manquez l'un des principaux services supplémentaires que RDBMSes fournir?
Nope. Mais mon fond est développeur d'applications web, nous travaillons avec des bases de données que dans la mesure où il faut :)
Une entreprise que j'ai l'habitude de travailler pour un produit (une webapp) qui a été conçue pour fonctionner sur les bases de données SQL à partir de plusieurs fournisseurs, et les "services supplémentaires" sont très différentes de DB DB qu'ils devaient être mises en œuvre séparément pour chaque DB. Il était donc moins de travail pour nous afin de déplacer les fonctionnalités des SGBD. Cette même recherche fulltext.
Donc, tout ce que je donne 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 que je suis en train de travailler sur maintenant est une webapp pour les données financières, les cours de la bourse et la comme. C'est un très bon match pour un document DB, de mon point de vue-je obtenir tous les avantages d'un DB (persistance et requêtes) sans tous les tracas.
Mais ces données sont assez indépendants les uns des autres, il n'y a aucun complexe des requêtes relationnelles. Recevez les dernières cotations par téléscripteur, obtenez des devis par symbole et la date gamme de, obtenir de la société meta-info, qui est à peu près tout. Un autre exemple que j'ai vu était une application de blog et les blogs ne sont pas caractérisés par massivement compliqué schémas de base de données.
Ce que j'essaie de dire, c'est que le succès de toutes les applications de document DBs je connais ont été avec des données qui n'ont pas beaucoup d'interrelations, en premier lieu: les Documents (comme lors d'une recherche Google), des articles de blog, des articles, des données financières.
J'attends qu'il existe des ensembles de données que la carte mieux SQL que pour le modèle de document, donc j'imagine SQL va survivre.
Mais pour ceux d'entre nous qui veulent juste un moyen simple de stocker et récupérer des données - et je soupçonne qu'il y a beaucoup de nous - document de bases de données (comme dans CouchDB) sont une aubaine.
