Conception D'une base de données non relationnelle [fermé]

je viens tout juste de commencer avec le DBs Non relationnel, et j'essaie toujours de m'y faire et de comprendre ce que serait le meilleur modèle. Et je ne peux parler que pour CouchDB.

J'ai encore quelques conclusions préliminaires:

avez-vous trouvé des conceptions alternatives qui fonctionnent bien mieux dans le monde non relationnel?

le centre d'intérêt de la conception change: la conception du modèle de document (correspondant aux tables de DB) devient presque hors de propos, alors que tout repose sur la conception des vues (correspondant aux requêtes).

le document DB sorte de swaps les complexités: SQL a des données rigides et des requêtes flexibles, DBS document sont l'inverse.

le modèle CouchDB est une collection de "documents JSON" (essentiellement des tables de hachage imbriquées). Chaque document a un ID unique, et peut être récupéré par ID. Pour toute autre requête, vous écrivez "vues", qui sont ensembles nommés de fonctions map / reduce. Les vues renvoient un ensemble de résultats sous la forme d'une liste de paires clé/valeur.

le truc 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 "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 interroger la base de données en utilisant des procédures stockées - chaque requête que vous voulez soutenir doit être prédéfinie.

la conception des documents est extrêmement souple. Je n'ai trouvé que deux contraintes:

• conserver les données connexes ensemble dans le même document, car il n'y a rien correspondant à une jointure.
• ne pas rendre les documents 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), depuis 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é que les ordres de grandeur de travail 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 la conception de tables DB (problème mineur)
• non 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 (c'est important!)
• vous pouvez potentiellement sauter le serveur d'application entier, car vous pouvez concevoir vos documents pour être récupéré directement par le navigateur utilisant AJAX et Ajouter un peu de polissage JavaScript avant qu'ils ne soient affichés comme HTML. (énorme!!)

pour les webapps normaux, les DBs basés sur les 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.

avez-vous frappé votre tête contre quelque chose qui semble impossible?

pas encore. Carte / 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 SQL. Il y a un assez petit nombre de primitives, donc obtenir les résultats dont vous avez besoin est principalement une question d'être créatif avec la façon dont vous spécifiez les clés.

il y a une limite en ce que les requêtes ne peuvent pas regarder deux ou plusieurs documents en même temps - pas de jointures ou autres types de relations multi-documents, mais rien jusqu'à présent n'a été insurmontable.

comme un exemple la limitation, les comptes et les sommes sont faciles mais les moyennes ne peuvent pas être calculées par une vue/requête CouchDB. Correction: retourner la somme et Compter séparément et calculer la moyenne sur le client.

avez-vous comblé le vide avec des schémas de conception, par exemple pour passer de l'un à l'autre?

Je ne suis pas sûr que ce soit faisable. C'est plutôt une refonte complète, comme traduire un programme de style fonctionnel en style orienté objet. 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 à cela est de regarder votre SQL pour les inserts et les requêtes communes: quelles tables et colonnes sont mises à jour quand un client passe une commande, par exemple? Et ceux qui pour des rapports de ventes mensuels? Cette information devrait probablement aller dans le même document.

C'est-à-dire: un document à commander, contenant L'identification du client et l'Identification du produit, avec 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 say Order et Customer 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 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 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 s'assurer que tout le monde en utilisant la base de données connaît les conventions. Puisque vous n'avez 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 qu'il souhaite, vous avez besoin à la fois de code de validation et de conventions pour prendre le relais. Surtout si vous travaillez avec des ressources externes.

quels sont les principaux services supplémentaires offerts par les Dgpgdr?

Non. Mais ma formation est Web Application developer, nous traitons avec des bases de données que dans la mesure où nous devons:)

une entreprise pour laquelle j'ai travaillé a fabriqué un produit (une webapp) qui a été conçu pour fonctionner à travers les bases de données SQL de plusieurs fournisseurs, et les" services supplémentaires " sont tellement différents de DB à DB qu'ils ont dû être mis en œuvre séparément pour chaque DB. Donc c'était moins de travail pour nous de déplacer la fonctionnalité hors du RDBMS. Cette même recherche fulltext.

donc ce que j'abandonne 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 travaille maintenant est une webapp pour les données financières, les cours des actions et autres. C'est un très bon match pour un document DB, de mon point de vue je reçois tous les avantages d'un DB (Persistance et requêtes) sans aucune des tracas.

mais ces données sont assez indépendantes les unes des autres, il n'y a pas de requêtes relationnelles complexes. Obtenir les dernières citations par téléscripteur, obtenir des citations par téléscripteur et la gamme de dates, obtenir des méta-informations de 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 caractérisés par des schémas de base de données très compliquées non plus.

ce que j'essaie de dire c'est que toutes les applications réussies de DBS document que je connais ont été avec des données qui n'ont pas beaucoup d'interrelations en premier lieu: Documents (comme dans la recherche Google), billets de blog, articles de nouvelles, 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 simplement un moyen simple de stocker et d'extraire des données - et je soupçonne qu'il y en a beaucoup d'entre nous - les bases de données de documents (comme dans CouchDB) sont une bénédiction.

je réponds à cela avec CouchDB au fond de mon esprit, mais je suppose que la plupart serait vrai pour d'autres DBs aussi. Nous nous sommes penchés sur L'utilisation de CouchDB, mais nous avons finalement décidé de ne pas l'utiliser puisque notre accès aux données n'est pas connu à l'avance et que l'évolutivité n'est pas le problème.

plus Difficile:

• prend repenser au niveau conceptuel de sorte qu'il est "plus difficile" car il est juste différent. Comme vous devez connaître vos modèles d'accès aux données à l'avance, aucun automatique la traduction peut être appliquée. Vous devriez ajouter le modèle d'accès au moins.
• la cohérence n'est pas traitée par la base de données mais doit être traitée dans la demande. Moins de garanties signifie une migration plus facile, un basculement et une meilleure évolutivité au prix d'une application plus compliquée. Une application doit traiter des conflits et des incohérences.
• liens qui croisent des documents (ou clé/valeur) doivent être traités au niveau de la demande également.
• type SQL des bases de données ont des IDEs qui sont beaucoup plus matures. Vous obtenez beaucoup de bibliothèques de soutien (bien que la superposition de ces bibliothèques rendent les choses beaucoup plus complexes que nécessaire pour SQL).

plus facile:

• plus rapide si vous connaissez vos modèles d'accès aux données.
• Migration / Fail-over est plus facile pour la base de données car aucune promesse ne vous est faite en tant que programmeur d'application. Bien tu obtiens une consistance éventuelle. Probablement. Enfin. Un certain temps.
• Une clé / valeur est beaucoup plus facile à comprendre qu'une ligne d'une table. Toutes les relations (arborescentes) sont déjà présentes, et les objets complets peuvent être reconnus.

la modélisation doit être à peu près la même, mais vous devez faire attention à ce que vous mettez dans un document: UML peut également être utilisé pour la modélisation OO ainsi que la modélisation DB, qui sont deux bêtes différentes déjà.

j'aurais aimé voir une bonne base de données ouverte oo bien intégrée avec C# / Silverlight. Juste pour rendre le choix encore plus difficile. :)

les fichiers plats ont longtemps été considérés comme obscurs et impraticables pour un ensemble de données de n'importe quelle taille. Cependant, des ordinateurs plus rapides avec plus de mémoire permettent de charger un fichier dans la mémoire et de le trier en temps réel, au moins pour des applications n et locales, à un seul utilisateur.

par exemple, vous pouvez habituellement lire un fichier de 10 000 enregistrements et le trier sur un champ en moins d'une demi-seconde, un temps de réponse acceptable.

bien sûr, il y a raisons d'utiliser une base de données au lieu d'un fichier plat -- opérations relationnelles, intégrité des données, capacité multi-utilisateur, accès à distance, plus grande capacité, standardisation, etc., mais la vitesse accrue de l'ordinateur et la capacité de mémoire ont rendu la manipulation en mémoire des données plus pratique dans certains cas.

les bases de données relationnelles que je vois dans la vie réelle ont tendance à ne pas être très bien normalisées du tout, contrairement à ce que vous prétendez. Quand on me le demande, les designers me disent que c'est surtout à cause de la performance. Les RDBM ne sont pas bons à joindre, donc les tables ont tendance à être beaucoup trop large d'un point de vue de la normalisation. Les bases de données orientées objet tendent à être bien meilleures à cet égard.

un autre point où les SGBDR ont des problèmes est la manipulation des clés dépendantes de l'historique/du temps.