Puis-je utiliser RavenDB (NoSQL) ou devrais-je simplement utiliser MySQL (RDBMS)?

Question

Je commence sur un système de gestion générale ASP.NET MVC 3 (la gestion de projet étant le premier composant). Maintenant, j'ai lu un peu sur RavenDB et cela semble très intéressant. L'une des plus grandes choses que j'aime à ce sujet est le fait que je n'aurais besoin d'aucun type sur ORM pour gérer les données de la base de données. Cela rendra mon code beaucoup plus propre et plus rapide. Cependant venant d'un arrière-plan travaillant exclusivement avec MySQL depuis plus de 6 ans, j'ai tendance à penser très en relation avec mes données. Il y a quelques choses qui semblent ne pas convenir à NoSQL. Je veux jeter ces choses là et peut-être que ces problèmes peuvent être traités dans une solution NoSQL et je pense juste trop sur le plan relationnel (encore une fois, peut-être que ce projet devrait être fait avec MySQL). Ce sont les questions que je pense à:

1. Idenifiers Unique: Je vais vouloir être en mesure d'avoir des identificateurs uniques pour beaucoup de choses. Pour des choses comme les projets, le nom devrait être unique et pourrait l'utiliser cependant quand il s'agit de tâches sous un projet, le titre peut ne pas être unique et c'est là que j'utiliserais un champ de quto-incrémentation mais je peux le faire dans RavenDB (à partir de ce que je peux dire)

2. Liaison: Utilisation pour les champs comme le statut et le type Je voudrais simplement utiliser un lien avec une clé étrangère. Maintenant, pour les relations un-à-plusieurs, je peux simplement utiliser le texte au lieu d'essayer de lier une clé étrangère (que vous n'avez pas dans NoSQL) mais avec un lien many-to-many, cela parce qu'un problème. Par exemple, j'ai l'intention d'avoir un système de marquage (comme ici) où la plupart des éléments peuvent avoir 1 à plusieurs étiquettes attachées à lui et ensuite je peux effectuer des recherches sur ces étiquettes pour les éléments. Existe-t-il un moyen de le faire dans NoSQL?

Est-ce un SGBDR vraiment le meilleur outil pour le travail ici ou suis-je pense tout simplement pas correctement le chemin et je peux accomplir « NoSQL » avec ce NoSQL (RavenDB)?

Answer 1

Ayende a écrit une publication "Modeling reference data in RavenDB" qui répond à certaines de vos questions concernant le lien. Vous aurez des copies des données entre le document de référence et vos autres documents et cette redondance est "ok" pour les bases de données de documents. Vous pouvez toujours créer des index ou des requêtes en fonction de l'ID ou du texte que vous stockez. Je préférerais SQL pour un système de transaction tel que l'application Comptes Recevables où vous devez effectuer des requêtes ad hoc. Avec la base de données de documents, vous devez vraiment réfléchir à la façon dont vous allez chercher vos données et construire des index à l'avance pour répondre à ces questions. RavenDB dispose également d'une fonction d'indexation dynamique qui apprend et met en cache les requêtes lancées sur la base de données.

Pour la gestion de projet où la majorité des éléments seraient des tâches, je pense qu'un RavenDB répondrait à vos besoins.

Answer 2

Je sais que c'est un ancien article. Peut-être que les documents n'étaient pas aussi bons à l'origine. Mais pour référence en cas d'autres trébuchent ici:

1. Raven est livré avec une stratégie de génération d'identifiant du document HiLo par défaut. Si vous stockez un nouveau document sans spécifier d'identifiant vous-même, vous obtiendrez un identifiant auto-incrémenté tel que "projects/1", "projects/2", etc. En savoir plus here.

2. La meilleure documentation sur les différentes manières de gérer les relations de document est here dans la documentation. Pour la situation que vous avez décrite, vous n'avez vraiment pas besoin d'un document séparé. Vous pouvez simplement intégrer un tableau de chaînes de noms de tag dans chaque élément. Les documents ne sont pas plats, ils peuvent être structurés. Et oui, vous pouvez toujours interroger sur eux.

J'espère que vous avez découvert cela par vous-même depuis la publication originale.