Arguments pour le choix de l'utilisation: RavenDB vs SQL Server-performance, fiabilité et simplicité [fermé]

puisque cette question invite les commentaires personnels, voici mon avis:

SQL Server n'est pas une base de données pour stocker quoi que ce soit sauf des données de rapport ad hoc. Il est splendide pour cela, des rapports ad-hoc, l'exploration de données, la découverte de relations en temps réel - et son optimal pour ces utilisations parce chemin en arrière quand Codd a conçu les règles, qui est ce qu'il a été conçu pour (voir le Conspiracy Driven Conspiracy pour plus de détails)

bien sûr, vous pouvez stocker d'autres types de données dans une base de données relationnelle. Par exemple, vous pouvez sérialiser votre état de domaine vers une base de données SQL Server et récupérer cet état à une date ultérieure, mais c'est une utilisation terrible d'un système relationnel. Si mauvais, en fait, que des couches entières de code (soi-disant 'couches de données', ou DALs), plusieurs milliers de lignes, sont nécessaires pour rendre ce genre de tâche à distance faisable, testable, maintenable.

le Grand Tour de confiance de plusieurs décennies a été pour les détaillants basés sur SQL de convainquez-nous qu'il n'y avait pas de meilleur moyen de stocker des données hiérarchiques / documentaires que la conversion en temps réel entre des structures de données radicalement différentes. DALs et le dernier ORM ont tous été trompés, mais, en fin de compte, ce ne sont rien de plus que des codecs pour rassembler vos bits d'avant en arrière entre différentes organisations de données - différents modèles sur le disque.

de la Folie!

alors oubliez toutes les discussions sur l'atomicité, la cohérence, isolation, durabilité. L'éléphant dans la salle est que si vous utilisez SQL Server et que vous n'êtes pas une société pharmaceutique qui exploite dynamiquement des cubes de données pour des inférences cachées au sein de grandes populations (êtes-vous? ensuite, vous utilisez probablement une mauvaise technologie pour stocker vos données.

Si, d'autre part, vous êtes un humble développeur d'application - un codeur qui, comme la plupart d'entre nous, tout simplement souhaite sérialiser domaine de l'état-d'une manière qui ne signifie pas que l'apprentissage d'une toute nouvelle série de les idéologies et la syntaxe alors, pour l'amour de Dieu, n'utilisent pas une base de données relationnelle. Il suffit de ne pas.

RavenDB? Je l'utilise depuis un certain temps (ayant évolué à travers DB4O et CouchBase) et je peux dire qu'il fait ce qu'il dit sur l'étain. Il stocke mes affaires et me les rend quand je demande. Je n'ai pas eu à écrire de couches de données ni à utiliser un ORM tiers. Je n'ai pas eu à apprendre un langage de requête structuré et je n'ai pas eu à verrouiller sur les extras pour faire le travail de recherche plein texte (RavenDB est basé sur Lucene donc tout "fonctionne"). So far So good.

Mais vraiment, n'importe ce que vous utilisez aussi longtemps qu'elle est, pour la tâche à portée de main, facile à code, rapide et efficace? Pour le développement d'applications normal, RavenDB est tout cela alors que SQL Server ne l'est pas. Cela ne veut pas dire que les SRD relationnels sont mauvais - ne blâmons pas la victime - je reconnais pleinement que pour certains développements spécialisés, vous pouvez en effet avoir besoin de quelque chose d'un peu plus ... exotique, une telle relationnelle la banque de données.

mais juste au cas où vous vous accrochez encore à l'épave, vous devez vous demander ceci: si nous avions tous utilisé des datastores simples, rapides et élégants qui correspondaient étroitement à nos besoins en tant que développeurs d'applications, et puis j'ai écrit un article d'opinion vous exhortant à adopter SQL Server alors vous seriez très probablement rire de moi ou me plaindre. Une chose est sûre - vous ne passerez pas à SQL Server. Nous démontrons ainsi que l'inertie seule est la force directrice qui maintient SQL Server dominant. L'inertie et de l'ignorance. L'inertie, l'ignorance et la cupidité des entreprises ....