NoSQL dans SQL Server

Cette question ne concerne pas la différence entre SQL et NoSQL. Je cherche une justification pour quelque chose qui n'a vraiment aucun sens pour moi en ce moment (peut-être à cause de mon manque de compréhension ou d'appréciation).

Nous avons commencé un nouveau projet à partir de zéro en utilisant MVC5, le code Entity Framework 6 d'abord et SQL Server 2008. Lorsque l'architecte a examiné le schéma de la base de données, il a été déclaré que toutes les clés étrangères et autres contraintes de ce type devraient être supprimées car il s'agit de la «logique métier» et doit être appliqué dans la couche métier du code d'application.

Mon opinion est que les clés étrangères font partie de l'intégrité des données / référentielles et n'imitent pas vraiment la logique métier. Je vois la logique métier comme plus le processus et la validation qui contrôlent ce que / quand / comment / pourquoi les références sont appliquées. Je peux en quelque sorte comprendre que les contraintes uniques sont sans doute des processus métier, mais pour moi, cela complète simplement la logique et fait partie de l'intégrité.

Un deuxième argument est que l'objectif est d'adopter une approche NoSQL des données. J'ai trouvé cela vraiment inhabituel et peu orthodoxe: compte tenu de l'utilisation de SQL-Server 2008, de la nécessité de créer des rapports, des données non évolutives en téraoctets et du manque de considération pour les technologies telles que Mongo, Raven, etc.

Quelqu'un a-t-il déjà rencontré un tel scénario auparavant? Pourquoi quelqu'un adopterait-il une approche NoSQL dans un serveur SQL conçu pour les données référentielles et ne voudrait-il pas de clés étrangères?

sql sql-server nosql

— Andy Clark
source

Discutez avec votre architecte de systèmes de la justification de ses conseils. Soit il a une très bonne raison qui s'applique à votre cas spécifique (une raison que nous ne serons pas nécessairement en mesure de deviner, sans savoir exactement en quoi consiste votre application), soit il est simplement incompétent.

— Arseni Mourzenko

J'ai vu de nombreuses bases de données implémentées de la même manière: pas de FK, pas de contraintes CHECK - à chaque fois qu'il s'agissait de bases de données conçues par des codeurs inexpérimentés qui ne connaissaient rien à l'architecture de la base de données, à l'intégrité référentielle, etc. Mais il est important pour vous d'en discuter avec votre collègue, au lieu de simplement supposer qu'il est incompétent.

— Arseni Mourzenko

Je suis légèrement confus; vous mentionnez l'utilisation du framework Entity (le code en premier) ... cela n'implique pas que vous créez des objets (au sens C #), puis laissez le framework Entity gérer la construction des équivalents de la base de données, auquel cas essayer d'ajouter / supprimer des FK, etc. est un exercice pour essayer de déjouer Entity Framework (qui est un peu comme la citation de Mark Twain à propos d'apprendre à un cochon à chanter?)

— Foon

Il y a trop de gens qui se prétendent «architectes», mais qui n'ont en fait aucune expérience du codage ou de la maintenance de systèmes plus gros.

— Doc Brown

Pertinent: thedailywtf.com/articles/The-Mythical-Business-Layer . "Si vous y réfléchissez, pratiquement chaque ligne de code dans une application logicielle est une logique métier." Cela s'étend à la base de données. "Mais il est tout aussi important - sinon plus - de garder à l'esprit que la quasi-totalité du code d'une application sera une logique métier. Il existe déjà suffisamment d'outils; votre application n'a pas besoin d'une couche générique " (c'est moi qui souligne). La personne qui recommande cela essaie probablement de transformer la base de données en une telle couche générique. En bref, ils mettent probablement les mots à la mode au-dessus de la réalité.

— jpmc26

Réponses:

Lorsqu'il a examiné le schéma de la base de données, il a déclaré que toutes les clés étrangères et autres contraintes de ce type devraient être supprimées car il s'agit d'une logique métier et devraient être appliquées au sein de la couche métier.

Ensuite, c'est un idiot, et un extrait de votre base de code est susceptible de se retrouver un jour sur The Daily WTF . Vous avez absolument raison de dire que son approche n'a pas de sens, et franchement, son explication non plus.

Essayez de lui expliquer que les contraintes d'intégrité référentielle ne sont pas de la «logique métier»; ils sont une norme d'exactitude avec sa propre vérification intégrée. La logique métier concerne ce que vous faites des données; l'intégrité consiste à s'assurer que les données elles-mêmes ne sont pas corrompues. Et si cela ne fonctionne pas ... eh bien, il est en charge. Vous pouvez soit suivre son plan et essayer d'atténuer quelque peu les dommages, soit commencer à chercher un meilleur endroit pour travailler. (Ou les deux.)

— Mason Wheeler
source

J'ai eu une réponse un peu plus diplomatique qui a essayé de trouver une raison (sensée) pour laquelle l'architecte pourrait faire cela. Après réflexion, je monte à bord avec cette réponse à la place.

— Blrfl

Whoa whoa, les mauvaises tentatives d'architecture sont une raison d'aller travailler ailleurs? Merde, je n'aurais jamais pu continuer à travailler n'importe où si j'avais adopté cette perspective.

— Kzqai

@Kzqai il y a aussi l'architecte qui méconnaît fondamentalement l'architecture. Cela commence à ressembler à la directive 595 et oui, si quelqu'un voulait me forcer à utiliser des marteaux pour mettre des vis dans un morceau de bois, je trouverais quelqu'un qui ne me forcerait pas à abuser des outils pour construire quelque chose.

L'intégrité référentielle est un sujet central de la théorie des bases de données, sans parler de toutes les bases de données qui la supportent dans le monde réel. De toute évidence, le collègue d'Andy a raison dans son analyse, le reste du monde universitaire et professionnel a 100% tort. Points bonus pour mentionner The Daily WTF .

@AndyClark Vous devez quitter cette fonction. La raison en est que c'est une bombe à retardement nucléaire dans le cœur de votre entreprise. Ce n'est qu'une question de temps lorsque la matière fécale empiète sur le ventilateur. Lorsque cela se produit, vous auriez la chance de travailler un poste de 72 heures, dans le pire des cas, vous chercheriez un emploi ... mieux vaut chercher un emploi lorsque vous avez un revenu.

— 2015

Je n'ai pas encore de raison de créer une clé étrangère

- Joel Spolsky

Mis à part les déclarations générales, il convient de reconnaître qu'il existe des raisons légitimes et fortes de choisir de ne pas utiliser les contraintes d'unicité ou de clés étrangères. La plupart vont quelque chose comme ça:

Performance. Faire des contrôles d'intégrité avec des transactions atomiques n'est pas gratuit. Et souvent, la base de données est la partie la plus difficile de votre architecture à évoluer. Peut-être que vous effectuez déjà les vérifications dans la logique de votre application et que vous préférez ne pas générer un deuxième impact sur les performances.
Manque de besoin. Peut-être que vos données sont sales, et vous êtes d'accord avec ça. Cela dépend beaucoup de ce que vous faites.

Voir aussi Qu'est-ce qui ne va pas avec les clés étrangères?

Mais cela ne correspond pas aux raisons de votre question.

Il s'agit d'une logique métier qui doit être appliquée au sein de la couche métier.

Cette raison est un peu étrange. L'unicité et d'autres contraintes d'intégrité sont en grande partie le domaine d'une base de données ACID. Votre code d'application ne peut pas approcher les garanties d'atomicité et d'intégrité de SQLServer. Si vous avez besoin d'une forte intégrité des données, vous seriez stupide d'ignorer la base de données.

Un deuxième argument est qu'ils veulent adopter l'approche NoSQL pour leur stockage de données et ne veulent donc pas que de telles restrictions soient en place.

La deuxième raison n'est pas vraiment une raison; c'est une conclusion. Bien qu'il soit vrai que les contraintes sont un compromis entre l'exactitude et les performances, et les bases de données NoSQL biaisent vers ces dernières.

Peut-être que votre architecte système a ces raisons légitimes à l'esprit, et vous avez mal entendu. Ou peut-être qu'il est un idiot bavard.

Dans tous les cas, il existe des raisons valables (mais pas universelles) de s'abstenir d'utiliser l'unicité et les contraintes de clé étrangère.

PS Si vous concluez que vous ne voulez pas de clés étrangères, vous pouvez toujours utiliser une base de données relationnelle. En général, les bases de données relationnelles sont plus matures que leurs homologues NoSQL. En tant que nœud unique, ils peuvent même être plus rapides , et une abstraction NoSQL peut être construite sur eux .

— Paul Draper
source

J'ose dire que Joel n'est pas un idiot, mais une réponse pleine d'esprit dans un podcast, sans aucune explication, à mon humble avis, vaut encore moins qu'une déclaration de n'importe quel idiot.

— Martin Ba

Joel est un tableur, pas un type de base de données, donc son ignorance des pratiques de base de données relationnelles standard n'est, je suppose, pas surprenante ... Aucune infraction, Joel. :-)

— Eric King

La citation réelle de Joel dans le contexte est que les technologies, telles que LINQ, fournissent une raison de prendre la peine de configurer une clé étrangère. Joel n'est pas un administrateur de bases de données et, en cherchant sur son blog et en étant un lecteur de longue date, je ne trouve rien de lui parlant du sujet ou essayant de donner des conseils sur l'optimisation des bases de données, la conception de modèles de données, etc. , mais il ne l'est pas et il ne l'a jamais été - ou ne l'a jamais prétendu! - un expert dans le domaine des bases de données ou de la modélisation de données. C'est comme citer Einstein à propos des intérêts composés - ou, d'ailleurs, des sandwichs. (Référence XKCD, vous êtes les bienvenus.) :)

— BrianH

Joel Spolsky est connu pour avoir des opinions fortes et controversées. Voir FogBugz est écrit dans un langage propriétaire ; L'injection de dépendances est trop compliquée (d'ailleurs, c'était la réponse la plus controversée sur Stackoverflow avant d'être fermée) ; Les bases de données XML sont lentes ; etc.

— BlueRaja - Danny Pflughoeft

@BlueRaja: Umm ... Les bases de données XML sont lentes, en particulier par rapport aux bases de données relationnelles. Depuis quand est-ce controversé ou une opinion?

— Mason Wheeler