Contraintes dans une base de données relationnelle - Pourquoi ne pas les supprimer complètement?

Y a-t-il une raison de créer des contraintes entre les tables (à l'intérieur de SQLserver) de nos jours? Si oui, quand? La plupart des applications dans mon domaine sont construites sur des principes d'objet et les tables sont jointes à la demande. La demande est basée sur le besoin de l'application. Je ne chargerai pas un tas de tables contraintes pour une simple recherche, qui à son tour (après action) nécessite une autre recherche simple.

Les outils ORM tels que EntityContext, Linq2Data, NHibernate gèrent également les contraintes par eux-mêmes, au moins vous savez quelles tables ont besoin les unes des autres. Faire des contraintes à l'intérieur du serveur revient à faire (forcer) les mêmes changements deux fois?

Ce n'est généralement pas une question à décider, mais cette base de données est conçue de manière très différente. La conception semble régulière, reflétant principalement les objets utilisés par les applications. Ce qui me dérange, ce sont toutes les contraintes configurées dans SQLserver avec "not cascade". Ce qui signifie que vous devez jouer "chercher et trouver" lors du codage de nouvelles requêtes de base de données. Certains cas nécessitent jusqu'à 10 niveaux d'une commande exacte pour effectuer une seule suppression.

Cela me surprend et je ne sais pas comment le gérer.

Dans mon monde simple, ce paramètre fait que les contraintes perdent l'essentiel. OK si la base de données était accessible à partir d'hôtes sans connaissance de la conception.

Comment agiriez-vous dans ce scénario?
Pourquoi ne pas simplement supprimer toutes les contraintes de db et les conserver au niveau de l'application?

Deux raisons générales de ne pas supprimer les contraintes de DB :

• Il est possible d'accéder à d'autres applications, maintenant ou à l'avenir , qui peuvent ou non utiliser ORM. Même si les développeurs de ces applications dupliquent fidèlement toutes les contraintes (ce qui peut être beaucoup plus difficile à utiliser avec des solutions non ORM de niveau inférieur), c'est toujours un travail supplémentaire. Et sinon, même une petite omission suffit pour briser l'intégrité du schéma ... ce que vous ne voulez pas risquer. Dans la plupart des entreprises, les données stockées dans leur base de données sont l'élément vital de leur entreprise, leur intégrité doit donc être garantie par tous les moyens. Et le meilleur moyen éprouvé pour y parvenir est d'implémenter autant de contraintes que possible dans la base de données.
• L'optimiseur de requêtes s'appuie beaucoup sur les contraintes connues au niveau de la base de données. Si vous supprimez les contraintes, les performances des requêtes peuvent commencer à se détériorer . Vous ne le remarquerez peut-être pas immédiatement, mais un jour, il vous frappera et il sera peut-être trop tard pour le réparer facilement. La nature des choses est que les performances de la base de données ont tendance à tomber en panne au moment du pic de charge, lorsqu'il y a le moins de possibilité d'apporter des améliorations de conception soigneuses et bien pensées, soutenues par des mesures de performances exactes et une analyse détaillée pour identifier les causes profondes.

Votre cas concret sonne comme si le schéma de base de données pouvait avoir été initialement généré par un outil ORM (ou conçu par une personne peu expérimentée dans le monde relationnel), il est donc sous-optimal du point de vue relationnel. Il est probablement préférable de l'analyser et de l'améliorer vers une conception relationnelle plus "naturelle", tout en restant cohérente avec les vues ORM. Il peut être utile d'impliquer un expert DB dans cette analyse.

Les applications peuvent aller et venir, mais les données vivent pour toujours. Dans mon entreprise, la DB a plus de 30 à 40 ans, elle vivra aussi longtemps que l'entreprise existera. Les applications changent, les développeurs vont et viennent. Il vaut mieux avoir l'intégrité et un bon modèle de données logique. De cette façon, quelqu'un peut consulter les données et obtenir une compréhension significative sans avoir à passer par une base de code complexe. Cela permet également de générer des rapports de manière significative. Les applications peuvent également et auront des bogues et la contrainte de base de données est une protection contre cela. Ma position par défaut est d'avoir autant de contraintes (FK et check) que possible.
La seule raison de ne pas avoir de contrainte serait que votre modèle de conception ne le permette pas, par exemple, table par hiérarchie ou problèmes de performances.

Ce qui me dérange, ce sont toutes les contraintes configurées dans SQLserver avec "not cascade".

Cela ne me dérange pas, cela signifie que quelqu'un a fait preuve de bon sens. Les suppressions en cascade sont souvent très mauvaises pour la base de données. En premier lieu, vous souhaitez parfois que la suppression échoue si vous avez des données dans des tableaux associés. Par exemple, si vous avez un client qui a une commande dans le passé, vous ne voulez pas qu'il soit supprimé ou vous perdez les données sur qui était la commande et une suppression en cascade nous débarrasserait de l'enregistrement qui vous gâcherait les rapports financiers .

Vous semblez penser que la facilité de développement est la chose la plus importante. Dans le monde des bases de données, ce n'est tout simplement pas vrai. L'intégrité des données est la première chose la plus critique suivie de près par les performances et la sécurité des données. S'il faut plus de temps pour écrire les requêtes, alors tant pis.

La base de données est généralement gérée par de nombreuses applications = un ou plusieurs sites Web ou applications de bureau, une application de création de rapports, des services Web, la fenêtre de requête, les processus ETL, etc. Si vous n'appliquez pas de contraintes au niveau de la base de données, vous perdez d'abord l'intégrité des données car l'une de ces applications peut ne pas suivre toutes les règles. Deuxièmement, vous devez coder ces contraintes plusieurs fois et les réécrire si vous décidez d'utiliser une autre application ultérieurement. Troisièmement, vous ne pouvez pas contrôler à l'avance s'il sera nécessaire d'effectuer une sorte de tâche de maintenance des données qui ne se fera pas via l'application (par exemple, corriger les données d'une mauvaise importation de données client ou modifier tous les 10 000 000 d'enregistrements d'un client à un autre client lorsque l'entreprise est achetée par un concurrent). Les développeurs d'applications ne font généralement pas

J'ai lu quelque part quelque part qui disait essentiellement: Les données sont la clé de votre application . Si vous n'accéderez JAMAIS aux données via votre interface utilisateur (et je veux dire toujours , comme maintenant et pour toujours, pour toute l'éternité ... ou la durée de vie de votre application, de toute façon), vous n'avez pas besoin de contraintes de base de données. Mais il y a toujours une chance que quelque chose d'autre que l'application elle-même ait besoin de toucher des données, par exemple un service Web, une API publique, une tâche de râteau / un travail SQL / cron / un script automatisé, alors vous vous épargnerez beaucoup d'ennuis potentiels dans le route en gardant les contraintes DB.

Je crois fermement que c'est le seul domaine du développement logiciel où vous ne devriez pas appliquer DRY (et je m'attends à une multitude de votes négatifs pour cette déclaration). Vos données sont le cœur et l'âme de votre application - si jamais elles sont corrompues au-delà de toute réparation, c'est: game over. Cela vaut la peine que l'OMI applique les contraintes partout où elles sont nécessaires. Si cela signifie sous la forme de déclencheurs et de contraintes au niveau de la base de données, de validations côté serveur sur le middleware et de Javascript côté client sur l'interface utilisateur (pour les applications Web), alors c'est l'OMI un mal nécessaire pour garantir que les données sont toujours vierges .

Savez-vous ce que signifie ORM? Mappage relationnel-objet. Citant Wikipedia "technique pour convertir des données entre des systèmes de types incompatibles ". Yup, les modèles relationnels et objets ne vont pas ensemble. Les ORM font une assez bonne conversion, en respectant les règles des deux types de systèmes. Les SGBDR sont organisés de telle manière que vous atteignez l'intégrité des données en utilisant des contraintes. En général, l'intégrité est une chose très agréable à avoir, donc les ORM ont tendance à les utiliser lors de la création d'un modèle de données pour stocker des données d'objet. Votre ORM a probablement une bonne raison d'utiliser des contraintes "non en cascade". Et si cela vous oblige à faire des requêtes compliquées au lieu de simplement créer / mettre à jour / supprimer certains objets, alors quelque chose ne va pas avec votre configuration ORM.

Si vous considérez le concept relationnel comme ennuyeux, alors pourquoi n'utilisez-vous pas la base de données d'objets? Il y a quelque temps, ils étaient lents (c'est pourquoi la plupart des gens utilisent encore des SGBDR) mais d'après ce que j'ai entendu, les choses ont un peu changé. Vous vous débarrasseriez de toutes les astuces relationnelles. Objets simplement à l'intérieur, objets à l'extérieur.

Eh bien, c'est ce qu'a fait eBay et ils ont probablement l'une des plus grandes bases de données au monde:

http://www.dba-oracle.com/oracle_news/news_ebay_massive_oracle.htm http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Malgré ce qui a été dit ci-dessus à propos de l'augmentation des performances par l'intégrité référentielle, elle peut en fait être dégradée; c'est pourquoi des bases de données massives ont abandonné leurs contraintes et fait le travail dans la couche application. Et pour autant que je sache, c'est la seule très bonne raison.

En supprimant ces contraintes, vous perdez essentiellement votre filet de sécurité qui maintient les données propres et qui entraîne ses propres problèmes. Comme pour tout, c'est un équilibre. Je suppose qu'en général, maintenir l'intégrité référentielle est la bonne chose à faire.

Ayant travaillé dans un environnement de développement à forte intégrité référentielle, je sais que du point de vue d'un développeur, cela peut être une douleur totale; souvent dans un environnement de développement, un peu de données sales n'a pas d'importance et trouver comment supprimer une ligne peut prendre une heure ou plus. Cependant, cela peut également être très utile, car les contraintes rendent le schéma explicite.

Premièrement - ma réponse: non, vous ne devez pas vous fier uniquement à l'application pour gérer vos données.

Cela pointe vers un débat plus large: les ORM ont encouragé une culture du dédain pour l'interaction DB "directe", souvent au détriment de la normalisation / intégrité référentielle. Les tableaux sont mappés de force à des hiérarchies d'objets arbitraires, au détriment de la conception implicite dans le modèle relationnel. Le découplage privilégié par OOP est sans doute sacrifié ici car l'application fait sentir sa conception dans la structure des données. Bien que l'ORM ait démontré une grande utilité, il semble être basé sur l'abus ou la méfiance de SQL.

De nouveaux paradigmes font (re) leur apparition, par exemple la programmation fonctionnelle. Si l'équipe de développement décide d'adopter une nouvelle méthodologie de programmation, quelles implications cela aura-t-il pour les données structurées selon les exigences de l'ORM?

Je suis d'accord avec @Jacek Prucia - Je pense que l'ORM est un mauvais match pour le SGBDR, j'opterais personnellement pour un DBAL sur RDBMS, ou opterais pour un OODB avec ORM.

Les contraintes sont votre seule garantie de cohérence et d'intégrité des données au niveau de la base de données. Bien sûr, vous pouvez appliquer des contraintes à l'aide de votre code d'application, mais que se passe-t-il si, à l'avenir, vous devez modifier directement les données? Vous pourriez comprendre comment maintenir l'intégrité des données, mais pas quelqu'un d'autre. Garder les contraintes au niveau des données garantit que l'intégrité est assurée même lorsque quelqu'un fait du singe dans des endroits qu'il ne comprend pas.

De plus, disons que votre application doit être réécrite, mais avec la même base de données en place. Toutes ces contraintes dans le code ne demandent que des bogues qui empêchent une entrée tout en permettant le passage de données erronées.

Lors du développement, restez simple. Les contraintes vous le permettent. (Cela dit, lorsqu'une contrainte renvoie une erreur, ne crachez pas la même erreur à l'utilisateur. Rendez l'erreur compréhensible.)

(En ce qui concerne le problème de la cascade: c'est une bonne chose. Je préfère lancer une erreur selon laquelle certains autres enregistrements doivent être supprimés en premier lieu, plutôt que de compter sur la cascade pour que tout soit correct. Les cascades sont agréables en théorie, mais pas nécessairement donc en pratique.)

Un problème avec les contraintes dans une base de données est qu'elles donnent au programme des informations limitées sur ce qui a échoué et comment y remédier. Cela signifie que, pour une manipulation en douceur, il est souvent nécessaire de répéter la vérification des contraintes dans l'application, et donc la vérification des contraintes de la base de données est un effort inutile.

Cela risque de compromettre l'intégrité des données, nous avons donc des compromis à faire ici. Pour les données importantes, garantir l'intégrité des données est presque toujours plus important que les performances, et il est préférable de faire échouer une transaction même si elle semble arbitraire que de gâcher les données.

Pour supprimer les contraintes en toute sécurité, il est donc primordial de sécuriser l'accès à la base de données afin que rien ne puisse changer la base de données sans vérifier les contraintes. Ce n'est pas fiable lors de l'écriture de nouvelles applications ou de la mise au point de moyens ad hoc pour gérer les données, car il suffit d'une erreur et la base de données est corrompue.

Par conséquent, pour éviter les contraintes de la base de données, il est nécessaire d'établir à l'avance ce qui peut et ce qui ne peut pas être fait avec la base de données, afin que toutes les applications puissent être écrites, examinées et testées de manière approfondie. Toutes les exigences de base de données doivent être établies à l'avance, et toute modification des exigences de base de données nécessitera un travail considérable. Il s'agit en quelque sorte d'une méthodologie de cascade gelée, qui ne fonctionne que dans des cas très spécifiques. (Concevoir, mettre en œuvre et respecter les exigences, c'est un peu comme marcher sur l'eau. Quelque chose doit d'abord être gelé, et s'il n'est pas assez gelé, les résultats peuvent être désastreux.)

Un cas où cela fonctionne est les applications d'entreprise massives comme PeopleSoft et SAP, où l'application fait déjà pratiquement tout, et il existe des moyens soigneusement définis pour l'étendre. Il existe d'autres possibilités, très rares.

Donc, à moins que vous ne travailliez sur un très grand projet d'entreprise (et je ne voudrais pas) ou que vous puissiez marcher sur de l'eau liquide, laissez ces contraintes dans la base de données.