Qu'est-il arrivé aux contraintes de la base de données?


46

Lorsque je passe en revue les modèles de base de données pour le SGBDR, je suis généralement surpris de constater peu de contraintes, voire aucune (à part PK / FK). Par exemple, le pourcentage est souvent stocké dans une colonne de type int(alors que ce tinyintserait plus approprié) et il n'y a pas de CHECKcontrainte pour restreindre la valeur à la plage 0..100. De même sur SE.SE, les réponses suggérant des contraintes de vérification reçoivent souvent des commentaires suggérant que la base de données est le mauvais endroit pour les contraintes.

Lorsque je pose la question sur la décision de ne pas appliquer de contraintes, les membres de l'équipe répondent:

  • Soit qu'ils ne savent même pas que de telles fonctionnalités existent dans leur base de données préférée. Cela est compréhensible pour les programmeurs utilisant uniquement des ORM, mais beaucoup moins pour les administrateurs de bases de données qui prétendent avoir plus de 5 ans d'expérience avec un SGBDR donné.

  • Ou qu'ils appliquent de telles contraintes au niveau de l'application et que la duplication de ces règles dans la base de données n'est pas une bonne idée, violant SSOT.

Plus récemment, je vois de plus en plus de projets dans lesquels même les clés étrangères ne sont pas utilisées. De même, j'ai lu quelques commentaires sur SE.SE qui montrent que les utilisateurs ne se soucient guère de l'intégrité référentielle, laissant l'application gérer.

En interrogeant les équipes sur le choix de ne pas utiliser de FK, elles disent que:

  • C'est PITA, par exemple, quand on doit supprimer un élément qui est référencé dans d'autres tables.

  • NoSQL est génial, et il n'y a aucune clé étrangère là-bas. Par conséquent, nous n'en avons pas besoin dans le SGBDR.

  • Ce n’est pas un gros problème en termes de performances (le contexte est généralement constitué de petites applications Web intranet fonctionnant sur de petits ensembles de données. Ainsi, même les index n’auraient pas trop d’importance; personne ne se soucierait de savoir si la performance d’une requête donnée dépassait 1,5 s. à 20 ms.)

Lorsque je regarde l'application elle-même, je remarque systématiquement deux tendances:

  • L’application nettoie correctement les données et les vérifie avant de les envoyer à la base de données. Par exemple, il n’existe aucun moyen de stocker une valeur 102sous forme de pourcentage dans l’application.

  • L'application suppose que toutes les données provenant de la base de données sont parfaitement valables. C’est-à-dire que s’il 102s’agit d’un pourcentage, soit que quelque chose, quelque part, tombe en panne ou s’affiche simplement tel quel à l’utilisateur, menant à des situations étranges.

  • Bien que plus de 99% des requêtes soient effectuées par une seule application, avec le temps, les scripts commencent à apparaître - soit des scripts exécutés manuellement si nécessaire, soit des tâches périodiques. Certaines opérations de données sont également effectuées manuellement sur la base de données elle-même. Les scripts et les requêtes SQL manuelles présentent un risque élevé d'introduire des valeurs non valides.

Et voici ma question:

Quelles sont les raisons pour modéliser des bases de données relationnelles sans contrainte de vérification et éventuellement sans clé étrangère?


Pour ce qui en vaut la peine, cette question et les réponses que j'ai reçues (en particulier l'intéressante discussion avec Thomas Kilian) m'ont amené à rédiger un article avec mes conclusions sur les contraintes de base de données .


8
Je le ressens pour vous, mais il semble que vous sachiez déjà pourquoi les contraintes sont une bonne idée. Il n’ya donc pas grand chose à ajouter sous forme de réponse. Je noterai cependant que le manque de contraintes n’est pas un phénomène nouveau. Je le vois depuis des décennies dans des bases de données conçues par des développeurs sans grande compréhension des bases de données relationnelles. Je pense que c'est rarement une décision de conception délibérée.
JacquesB

1
@JacquesB: vous pouvez poster une réponse, car «je le vois depuis des décennies» donne une vision très différente de celle que j’avais d’un phénomène apparu il ya trois ou quatre ans (étant donné que j’ai travaillé moins de décennie, ma vision du phénomène est probablement fausse). Ainsi, les conclusions seraient également très différentes.
Arseni Mourzenko

1
Nous travaillons avec beaucoup de clients. Et si le déploiement d'une nouvelle version de notre logiciel est un jeu d'enfant, il est difficile de mettre à jour toutes les bases de données. C'est pourquoi nous avons le plus de contraintes dans les logiciels. Ohh ouais, un minuscule pour cent n'est souvent pas une bonne idée, car les pourcentages peuvent être des fractions.
Pieter B

1
Voter pour ré-ouvrir cette question car elle a été fermée à tort comme "principalement basée sur l'opinion" lorsque les réponses jusqu'à présent montrent que ce n'est pas le cas.
David Arno

3
Je suis avec toi à 110%.
Periata Breatta

Réponses:


28

Il est important de distinguer les différents cas d'utilisation des bases de données.

La base de données professionnelle traditionnelle est accessible par plusieurs applications et services indépendants et peut-être directement par des utilisateurs autorisés. Il est essentiel de disposer d'un schéma bien pensé et de contraintes au niveau de la base de données, afin qu'un bogue ou un oubli dans une seule application ne corrompe pas la base de données. La base de données est critique pour l'entreprise, ce qui signifie que des données incohérentes ou corrompues peuvent avoir des résultats désastreux pour l'entreprise. Les données vivront éternellement pendant que les applications vont et viennent. Ce sont les emplacements qui peuvent avoir un DBA dédié pour assurer la cohérence et la santé de la base de données.

Mais il existe également des systèmes dans lesquels la base de données est étroitement intégrée à une seule application. Applications autonomes ou applications Web avec une seule base de données intégrée. Tant que la base de données est accessible exclusivement par une seule application, vous pouvez envisager des contraintes redondantes, à condition que l'application fonctionne correctement. Ces systèmes sont souvent développés par des programmeurs qui se concentrent sur le code d’application et n’ont peut-être pas une compréhension approfondie du modèle relationnel. Si l'application utilise un ORM, les contraintes peuvent être déclarées au niveau ORM sous une forme plus familière aux programmeurs d'applications. Dans le bas de gamme, nous avons des applications PHP qui utilisent MySQL. Pendant longtemps, MySQL n’a pas du tout supporté les contraintes de base. Il fallait donc s’appuyer sur la couche application pour assurer la cohérence.

Lorsque des développeurs de ces différents horizons se rencontrent, vous obtenez un choc de culture.

Dans ce mélange, nous obtenons la nouvelle vague de bases de données distribuées de "stockage en nuage". Il est très difficile de garder une base de données distribuée cohérente sans perdre les avantages en termes de performances. Par conséquent, ces bases de données évitent souvent les contrôles de cohérence au niveau de la base de données et permettent aux programmeurs de la gérer au niveau de l'application. Les différentes applications ont des exigences de cohérence différentes, et bien que le moteur de recherche de Google privilégie la disponibilité sur la cohérence de ses serveurs, je suis prêt à parier que son système de paie s'exécute sur une base de données relationnelle avec de nombreuses contraintes.


5
+! 1 pour avoir mentionné l'éléphant dans la pièce: l'hypothèse fausse selon laquelle une application utilise un seul DB et qu'un seul est utilisé par une seule application
Tulains Córdova

4
@ TulainsCórdova, je pensais que l'éléphant dans la pièce était le système de paie de Google. :)
Machado

5
@Machado C'est un génie: "Je suis prêt à parier que leur système de paie fonctionne sur une base de données relationnelle avec beaucoup de contraintes."
Tulains Córdova

2
Il est également utile de disposer de bases de données correctement contraintes, car le code de votre application n'est pas ACID.
Matthew Whited

3
Juste pour souligner le commentaire de @MatthewWhited, il n'est pas possible pour les applications d'appliquer certains types de contraintes inter-lignes / inter-tables sans effectuer de verrouillage et d'exécuter des requêtes supplémentaires. Un SGBDR peut le faire à un coût bien moindre.
David Aldridge

15

De nos jours, de plus en plus de systèmes fonctionnent dans des environnements distribués, sur le cloud et adoptent la technique de "dimensionnement" au lieu de "redimensionnement". C'est encore plus important si vous utilisez des applications en ligne avec Internet, telles que des applications de commerce électronique.

Cela dit, toutes les applications supposées évoluer sont contraintes par le théorème CAP , où vous devez choisir 2 des 3: cohérence, disponibilité et tolérance de partition (tolérance aux pannes réseau).

En étudiant le théorème de la PAC, vous constaterez qu'il n'y a pas beaucoup de choix, mais de choisir de perdre la disponibilité ou la cohérence, car vous ne pouvez JAMAIS vraiment faire confiance au réseau 100% du temps.

En général, plusieurs applications peuvent se permettre d’être incohérentes pendant un laps de temps raisonnable, mais ne peuvent pas se permettre d’être indisponibles pour les utilisateurs. Par exemple, une chronologie légèrement non ordonnée sur Facebook ou Twitter est préférable à un accès illimité à une chronologie.

Ainsi, plusieurs applications choisissent de laisser tomber les contraintes de bases de données relationnelles, car les bases de données relationnelles sont très performantes en termes de cohérence, mais au détriment de la disponibilité.

Note personnelle: je suis aussi un peu démodé et je travaille avec de très vieux systèmes financiers où la cohérence des données est la plupart du temps une exigence primordiale, et je suis un grand fan des contraintes de base de données. Les contraintes de base de données constituent la dernière ligne de défense contre des années et des années de mauvais développement et les équipes de développeurs qui vont et viennent.

"Est modus in rebus". Continuons à utiliser la cohérence DB "de bas niveau" où la cohérence est une exigence de première classe. Mais parfois, le laisser partir n'est pas un grand péché après tout.

-- MODIFIER: --

Comme il y a une petite modification dans la question, il y a une autre raison légitime pour supprimer des contraintes dans la base de données, IMO. Si vous concevez un produit à partir de zéro et que votre système prend en charge la technologie multi-bases de données, vous pouvez vous contenter du plus petit dénominateur commun parmi les bases de données prises en charge, et éventuellement abandonner l'utilisation de toute contrainte, laissant ainsi toute la logique de contrôle. ton application.

Bien que cela soit légitime, c'est aussi une zone grise pour moi, car je ne trouve aucun moteur de base de données aujourd'hui qui ne prend pas en charge des contraintes simples comme celle proposée dans la question initiale.


"Je ne trouve aucun moteur de base de données aujourd'hui qui ne supporte pas des contraintes simples comme celle proposée dans la question initiale." MySQL supporte-t-il encore les contraintes CHECK?
Vincent Savard

@VincentSavard, peut-être pas l'exact CHECK MS SQL, mais une sorte de restriction: dev.mysql.com/doc/refman/5.7/fr/constraint-invalid-data.html
Machado

@Machado - il ne s'agit toutefois pas de contraintes spécifiques, mais plutôt d'identifier le moment où les requêtes incluent des données qui ne peuvent pas être représentées dans les types appropriés. Ce qui représente une nette amélioration par rapport à la situation d'il ya quelques années lorsque MySQL a simplement ignoré ces valeurs en silence.
Periata Breatta

1
@PeriataBreatta, en passant, je n'ai jamais vraiment compris pourquoi MySQL était la base de données OSS "de facto" choisie par les développeurs de sites Web, alors que PostgreSQL était entièrement disponible et plus évolué. Peut-être que c'était plus facile à installer, je ne sais pas.
Machado

@machado - Je ne peux pas en être sûr , mais je sais qu'au tout début (au milieu des années 90), j'avais tendance à préférer mysql à postgres (qui n'a été renommé postgresql que plus tard) en raison d'une idée fausse que postgres ne supportait pas SQL (ses premières versions ne le faisaient pas - il avait son propre langage de requête appelé "postquel" - et je n'avais pas suivi son développement, donc je n'avais pas réalisé qu'ils avaient ajouté le support SQL à peu près le même temps, mysql est devenu disponible). Si cette idée fausse était commune, il est possible que mysql ait pris de l'avance juste à cause de cela. Et une fois en avance, les effets de réseau ont pris le relais.
Periata Breatta

10

Quelles sont les raisons pour modéliser des bases de données relationnelles sans contrainte de vérification et éventuellement sans clé étrangère?

Premièrement, précisons que je ne parle ici que de RDBM, pas de bases de données non-SQL.

J'ai vu quelques bases de données sans FK ni PK, encore moins vérifier les contraintes, mais pour être honnête, elles sont minoritaires. Peut-être parce que je travaille dans une grande entreprise.

Au fil des années, je peux affirmer que certaines raisons peuvent être:

  • Dans le cas des programmeurs débutants ou amateurs , de nombreuses compétences en modélisation
  • Utilisation étendue ou presque exclusive des ORM sans contact réel avec le monde des bases de données
  • Absence d'un DBA ou d'un autre expert en modélisation de données dans une équipe ou un petit projet
  • Manque d'implication du DBA ou de l' expert en modélisation de données dans les premières étapes du développement
  • Les décisions de conception délibérés par une partie de la communauté des développeurs qui considère que même une contrainte de vérification qui impose qu'une certaine colonne ne peuvent avoir 1,2 or 3comme valeur, ou que la colonne « âge » doit être >= 0est « ayant la logique métier dans la base de données » . Même les clauses par défaut sont considérées par certains comme une logique métier n'appartenant pas à une base de données, comme vous pouvez le constater dans plusieurs questions et réponses récentes de ce site. Les développeurs qui en tiennent compte utiliseraient évidemment le moins de contraintes possible et feraient tout en code, même l’intégrité référentielle et / ou l’unicité. Je pense que c'est une position extrême.
  • Utilisation de RDBM en tant que stockages clé-valeur , soit pour émuler un comportement no-SQL, soit parce que les requêtes étaient assez simples pour être satisfaites en utilisant des tables RDBMS en tant qu'isolements de référentiels clé-valeur.
  • En supposant que "l'application" écrit toujours dans la base de données et que personne ne devra jamais effectuer un chargement massif de données, ni modifier ou insérer des lignes via un client SQL (dans de nombreux cas, corriger les données incorrectes insérées dans l'application). Dans le meilleur des cas, il y aura toujours une autre application (en plus de "l'application") émettant des instructions DML vers la base de données: un client SQL.
  • Ne réalisant pas que les données appartiennent au propriétaire de l'entreprise , pas à l'application.

Cela dit, je voudrais dire que les SGBDR sont des logiciels très avancés qui ont été construits sur des épaules de géants et se sont révélés très efficaces pour de nombreuses exigences métier, libérant les programmeurs de tâches mondaines de mise en œuvre de l'intégrité référentielle. de fichiers binaires ou de fichiers texte. Comme je le dis toujours, "nous ne vivons plus dans un monde avec une seule application, une base de données" . À tout le moins, un client SQL émettra des fichiers DML en plus de "l'application". Donc, la base de données doit se défendre des erreurs humaines ou de programmation dans une mesure raisonnable

Dans ces types d’exigences bien connus où le SGBDR n’évolue pas bien, nous incluons bien sûr la technologie no-SQL . Mais il est inquiétant de constater la prolifération des bases de données relationnelles sans contrainte, où des milliers de lignes de code (générées ou typées) sont consacrées à l'application de ce que le SGBDR devrait vous appliquer de manière plus efficace.


3

Il existe des contraintes externes qui déterminent les décisions technologiques. Il existe peu de situations dans lesquelles vous avez le besoin et / ou le luxe d'utiliser régulièrement des contraintes de champ de base de données.

  1. Les entreprises ont des développeurs pour les applications et la base de données avec DBA, mais la plupart des développeurs ne travaillent pas dans ce type d'environnement. Ils font tout ce qu'ils peuvent dans le code. En outre, certains membres de la base de données ne sont pas impliqués dans les règles métier. Ils sont principalement là pour faire fonctionner les choses. Ils ne feront jamais pression pour des contraintes dans la base de données. Devoir gérer des applications existantes, des intégrations, des migrations, des fusions, des acquisitions, une contrainte de base de données peut être la meilleure solution.
  2. La surcharge de la base de données peut créer un goulot d'étranglement qu'il n'est pas facile de résoudre en jetant plus de machines sur le problème. Il existe des situations dans lesquelles le langage de base de données ne résout pas certains problèmes de programmation sans subir un impact important sur les performances. Vous ne pouvez donc pas planifier l'utilisation d'une contrainte pour tout. Stackoverflow a un serveur de base de données, car lancer un problème sur deux est un défi.
  3. Tests automatisés - ils y parviennent, mais de nombreux développeurs de base de données sont en retard avec les frameworks IDE / testing.
  4. Déploiement - plus de données de base de données compliquent les choses. Que se passe-t-il lorsqu'une mise à jour de la base de données d'un client n'est pas autorisée car certaines données violent la contrainte? Fin du jeu sauf si vous avez un moyen de résoudre ce problème. Dans votre application, vous pouvez décider de laisser l'utilisateur gérer cela au besoin ou demander à un administrateur de le faire en lot.
  5. Seule l'application / api / service écrira des données dans la base de données, alors pourquoi s'en préoccuper? Cela tient la plupart du temps, c'est pourquoi ce n'est pas courant.
  6. Il est déjà assez difficile de gérer les erreurs de base de données en l'absence de centaines de violations de contraintes, si tout se gâte. La plupart sont heureux d'établir une connexion et d'obtenir le nom de la table correct.

De nombreuses équipes de développement ne veulent pas donner trop de contrôle à un développeur de base de données. Vous avez de la chance si vous en avez plus d'un, les vacances sont donc très amusantes. Peu exigent un contrôle absolu sur le domaine de la base de données et assument la responsabilité de chaque requête, règle métier, performance, disponibilité, sécurité et des données transmises à quel type de RAID. Voici les procédures stockées que vous êtes autorisé à exécuter. S'amuser. Ne pense même pas à toucher une table.


2

C’est un problème avec lequel j’ai lutté tout au long de ma carrière (près de 40 ans) et aussi lors de la rédaction de mon SGBD. Une description de mon point final est ici: http://unibase.zenucom.com . Alors voici mes pensées.

  1. De manière générale, la plupart des contraintes sont mieux gérées dans l'application, de sorte que différentes parties de l'application puissent appliquer différentes contraintes. Par exemple, un code d'état peut ne pas s'appliquer dans toutes les juridictions.
  2. En passant, méfiez-vous de%. Les marges sont> 100% ou vous faites faillite :)
  3. Les contraintes sont mieux décrites négativement. c'est-à-dire ce qu'ils ne peuvent pas être, pas ce qu'ils devraient être. C'est toujours une liste plus simple.
  4. Les clés étrangères sont toujours bonnes et doivent être utilisées. Arrêt complet. FK est l’une des rares constructions sémantiques d’un SGBDR et très utile. La plus grande difficulté est de décider s'il faut laisser une valeur en suspens si le FK est supprimé ou utiliser des lignes dépendantes pour ne pas supprimer l'enregistrement FK.
  5. Les contraintes dans le monde réel sont généralement plus complexes qu'une restriction de valeur de champ unique.
  6. Certaines contraintes, même au niveau de l'application, vont à l'encontre des bonnes opérations. par exemple, un contrôle de date agressif masque les erreurs dans des dates apparemment bonnes. Vous avez besoin d’une erreur d’opérateur pour obtenir une mesure des erreurs dans des dates qui sembleraient autrement raisonnables.

1

Les contraintes de base de données étaient peut-être une bonne idée, mais qu'en est-il d'une utilisation pratique? Prenez votre contrainte de pourcentage. Si vous appliquez cela, votre base de données rejettera avec plaisir les pourcentages invalides. Puis? Vous aurez besoin d'une logique métier pour gérer l'exception. Ce qui signifie en réalité que la logique métier qui écrit un mauvais pourcentage a déjà échoué ailleurs. En bref, la seule contrainte pratique qui reste est celle que vous voyez (comme PK / FK).


15
Je suis poliment en désaccord avec cela. Si vous avez réellement besoin de cohérence des données, les contraintes de base de données sont indispensables, en particulier si votre logique métier échoue. Ainsi, vous décrivez le scénario d’une panne silencieuse, dans laquelle les dommages causés par une erreur de pourcentage erronée seraient propagés plus loin dans le système. Si vous avez une contrainte de base de données à ce sujet, vous échouerez rapidement et donnerez ainsi aux développeurs de la logique métier une chance de voir l'erreur à l'avance et de corriger le système de la logique métier au lieu d'y laisser des données corrompues.
Machado

5
D'après ce que je comprends, si le pourcentage de contrainte est violé, vous n'avez pas à gérer cette exception, car une telle violation indique qu'il y a un bogue dans votre code en premier lieu (soit quelqu'un a utilisé un entier simple à la place d'une instance de Percentageclasse, ou il y a une erreur dans la validation elle-même), par opposition à un cas exceptionnel (comme une connexion réseau est en panne). Pour moi, la violation devrait conduire à HTTP 500 pour une application Web ou à un blocage pour une application de bureau, puis être consigné et corrigé.
Arseni Mourzenko

7
@ThomasKilian: Nope; exactement le contraire. Les mauvaises données n'entreront pas, en particulier parce que les contraintes de base de données sont présentes. Si votre logique métier est correcte dans le code, vous ne violerez jamais ces contraintes. Si un bogue survient dans le code, ces contraintes vous alerteront de ce bogue, tout en protégeant la base de données.
Arseni Mourzenko

9
@ThomasKilian: Je ne pense pas que tout le monde plaide contre « Redresser en premier lieu » - il est probablement plus que tout le monde avec un peu d'expérience sait qu'il est une mauvaise idée de concevoir un système sur l'hypothèse que vous voulez obtenir tout droit la première fois et pas de bugs ou erreurs ne jamais se produire pendant la durée de vie du système. Les contraintes de base de données garantissent qu'un bogue ou une erreur ne corrompe pas la base de données.
JacquesB

3
@JacquesB Je me bats contre les éoliennes. Si vous placez la logique applicative dans la base de données, elle peut aussi bien échouer qu'en premier lieu et ne pas vous enregistrer de la même manière. Mais (!) Vous avez maintenant une logique d’affaires à laquelle elle n’appartient pas. Croire que la base de données peut sauver votre logique métier pourrie est tout simplement faux. La logique dans la base de données doit suivre les mêmes règles que toute la logique métier.
Qwerty_so

1

Plus souvent, de nos jours, les gens utilisent des logiciels (par exemple Entity Framework) pour générer automatiquement des tableaux et des colonnes. L'idée est qu'ils n'ont pas besoin de compétences en SQL, libérant ainsi la capacité du cerveau.

Il est souvent irréaliste de penser que les logiciels vont "résoudre les problèmes", et cela ne crée pas les contraintes qu'un humain pourrait créer.

Pour de meilleurs résultats, créez des tables à l'aide de SQL et ajoutez des contraintes manuellement, mais certaines personnes ne peuvent pas le faire.


Certains frameworks supportent l'ajout de PK et de FK (semi) automatiquement, bien sûr.
David Aldridge
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.