Qu'est-il arrivé aux contraintes de la base de données?
Lorsque je passe en revue les modèles de base de données pour SGBDR, je suis généralement surpris de trouver peu ou pas de contraintes (à part PK/FK). Par exemple, le pourcentage est souvent stocké dans une colonne de type int (alors que tinyint serait plus approprié) et il n'y a pas de contrainte CHECK pour limiter la valeur à une plage de 0 à 100. De même sur SE.SE, les réponses suggérant des contraintes de vérification reçoivent souvent commentaires suggérant que la base de données n'est pas le bon endroit pour les contraintes.
Lorsque je pose des questions 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. Il est compréhensible des programmeurs utilisant uniquement des ORM, mais beaucoup moins des DBA qui prétendent avoir plus de 5 ans d'expérience avec un SGBDR donné.
Ou qu'ils imposent de telles contraintes au niveau de l'application, et 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 où même les clés étrangères ne sont pas utilisées. De même, j'ai vu quelques commentaires ici sur SE.SE qui montrent que les utilisateurs ne se soucient pas beaucoup de l'intégrité référentielle, laissant l'application la gérer.
Lorsqu'elles interrogent les équipes sur le choix de ne pas utiliser de FK, elles répondent que:
C'est PITA, par exemple quand il faut supprimer un élément référencé dans d'autres tables.
NoSQL bascule, 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 de petites applications Web intranet travaillant sur de petits ensembles de données, donc en effet, même les index n'auraient pas trop d'importance; personne ne se soucierait si les performances d'une requête donnée passent de 1,5 s . à 20 ms.)
Lorsque je regarde l'application elle-même, je remarque systématiquement deux schémas:
L'application nettoie correctement les données et les vérifie avant de les envoyer à la base de données. Par exemple, il n'y a aucun moyen de stocker une valeur
102en pourcentage via l'application.L'application suppose que toutes les données provenant de la base de données sont parfaitement valides. Autrement dit, si
102vient sous forme de pourcentage, soit quelque chose, quelque part va planter, ou il sera simplement affiché tel quel pour l'utilisateur, conduisant à des situations étranges.Alors que plus de 99% des requêtes sont effectuées par une seule application, au fil du temps, les scripts commencent à apparaître, soit des scripts exécutés à la main si nécessaire, soit des tâches cron. 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'introduction de valeurs non valides.
Et voici ma question:
Quelles sont les raisons de modéliser des bases de données relationnelles sans contraintes de vérification et éventuellement même sans clés étrangères?
Pour ce que ça vaut, cette question et les réponses que j'ai reçues (en particulier la discussion intéressante avec Thomas Kilian) m'ont amené à écrire n article avec mes conclusions sur le sujet des contraintes de base de données .
Il est important de distinguer les différents cas d'utilisation des bases de données.
La base de données commerciale traditionnelle est accessible par plusieurs applications et services indépendants et peut-être directement par des utilisateurs autorisés. Il est essentiel d'avoir un schéma et des contraintes bien pensés au niveau de la base de données, donc un bogue ou une erreur 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 pour toujours pendant que les applications vont et viennent. Ce sont les endroits 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 où la base de données est étroitement intégrée à une seule application. Applications autonomes ou application Web avec une seule base de données intégrée. Tant que la base de données est exclusivement accessible par une seule application, vous pouvez considérer les contraintes comme redondantes - tant que l'application fonctionne correctement. Ces systèmes sont souvent développés par des programmeurs en mettant l'accent sur le code d'application et 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 PHP applications utilisant MySQL, et depuis longtemps MySQL ne supportait pas du tout les contraintes de base, donc vous aviez de vous fier à la couche application pour assurer la cohérence.
Lorsque des développeurs de ces différents horizons se rencontrent, vous obtenez un choc culturel.
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 conserver une base de données distribuée cohérente sans perdre les performances, de sorte que ces bases de données évitent souvent les contrôles de cohérence au niveau de la base de données et permettent essentiellement aux programmeurs de la gérer au niveau de l'application. Différentes applications ont des exigences de cohérence différentes, et bien que le moteur de recherche de Google recherche la priorité sur la disponibilité sur la cohérence sur leurs serveurs, je suis prêt à parier que leur système de paie fonctionne sur une base de données relationnelle avec beaucoup de contraintes.
De plus en plus de systèmes fonctionnent aujourd'hui dans des environnements distribués, sur le cloud et adoptent la technique de "scale out", au lieu de "scale up". C'est encore plus important si vous avez affaire à des applications en ligne accessibles sur Internet, telles que des applications de commerce électronique.
Cela étant dit, toutes les applications censées évoluer sont contraintes par le CAP Theorem , où vous devez choisir 2 sur 3: cohérence, disponibilité et tolérance de partition (tolérance aux pannes du réseau).
En étudiant le théorème de la PAC, vous verrez 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 une durée raisonnable, mais ne peuvent pas se permettre d'être indisponibles pour les utilisateurs. Par exemple, une chronologie légèrement non ordonnée dans Facebook ou Twitter vaut mieux que de ne pas avoir accès à une chronologie du tout.
Ainsi, plusieurs applications choisissent de laisser aller les contraintes des bases de données relationnelles, car les bases de données relationnelles sont vraiment bonnes en cohérence, mais au détriment de la disponibilité.
Note personnelle: je suis démodé aussi, et j'ai travaillé avec de très vieux systèmes financiers où la cohérence des données est une exigence de première classe la plupart du temps, et je suis un grand fan des contraintes de base de données. Les contraintes de base de données sont la dernière ligne de défense contre des années et des années de mauvais développement et des équipes de développeurs qui vont et viennent.
"Est modus in rebus". Continuons à utiliser la cohérence "bas niveau" de la base de données, 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.
-- ÉDITER: --
Puisqu'il y a une petite modification dans la question, il y a une autre raison légitime de supprimer les contraintes dans la base de données, IMO. Si vous concevez un produit à partir de zéro, où vous concevez votre système pour prendre en charge la technologie multi-base de données, vous pouvez vous contenter du dénominateur le moins commun parmi les bases de données prises en charge, et éventuellement abandonner l'utilisation de toutes les contraintes, laissant toute la logique de contrôle pour ton application.
Bien que ce soit légitime, c'est aussi une zone grise pour moi, car je ne trouve pas aujourd'hui de moteur de base de données qui ne supporte pas de contraintes simples comme celui proposé dans la question d'origine.
Quelles sont les raisons de modéliser des bases de données relationnelles sans contraintes de vérification et éventuellement même sans clés étrangères?
Tout d'abord, clarifions que je ne parle ici que de RDBM, pas de bases de données sans SQL.
J'ai vu quelques bases de données sans FK ni PK, sans parler de vérifier les contraintes mais pour être honnête, elles sont minoritaires. Peut-être parce que je travaille dans une grande entreprise.
D'après mon expérience au fil des ans, je peux dire que certaines raisons peuvent être:
- Dans le cas des programmeurs débutants ou hobby, un l ack de compétences en modélisation
- tilisation étendue ou presque exclusive des ORM sans réel contact avec le monde de la base de données
- Absence de DBA ou autre modélisation de données expert en équipe ou petit projet
- Manque d'implication du DBA ou modélisation des données expert dans les premières étapes du développement
- décisions de conception délibérées 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 peut avoir que
1,2 or 3comme valeur, ou que la colonne "âge" doit être>= 0est "avoir une 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 qui n'appartient pas à une base de données, comme vous pouvez le voir dans plusieurs questions et réponses récentes sur ce site. Ces développeurs qui le considèrent ainsi utiliseraient évidemment le moins de contraintes possible et feront tout dans le code, même l'intégrité et/ou l'unicité référentielle. Je pense que c'est une position extrême. - tilisation de RDBM comme stockages de valeurs-clés, soit pour émuler un comportement sans SQL, car les exigences étaient suffisamment simples pour être satisfaites en utilisant des tables RDBMS comme isolats de référentiels de valeurs-clés.
- en supposant que la base de données sera toujours écrite par "l'application" et que personne n'aura jamais besoin de faire un chargement de données massif, ni de modifier ou d'insérer des lignes via un client SQL (dans de nombreux cas pour corriger les mauvaises données que l'application a insérées). Dans le meilleur des cas escenario, 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 les épaules de géants et se sont révélés très efficaces pour de nombreuses exigences commerciales, libérant les programmeurs de tâches banales d'imposer l'intégrité référentielle sur une série de fichiers binaires ou de fichiers texte. Comme je le dis toujours "nous ne vivons plus dans un monde avec une application et une base de données". À tout le moins, un client SQL émettra des fichiers DML en plus de "l'application". La base de données doit donc se défendre contre les erreurs humaines ou de programmation dans une mesure raisonnable
Dans ces types d'exigences bien connus où le SGBDR ne s'adapte pas bien, par tous les moyens, adoptez la technologie sans SQL. Mais cela inquiète la prolifération de bases de données relationnelles sans contraintes où des milliers de lignes de code (générées ou tapées) consacrées à appliquer ce que le SGBDR devrait appliquer pour vous de manière plus efficace.
Il existe des contraintes externes qui déterminent les décisions technologiques. Il y a peu de situations où vous avez le besoin et/ou le luxe d'utiliser régulièrement des contraintes de champ de base de données.
- Les entreprises ont des développeurs pour les applications et les bases 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 en code. De plus, certains du côté de la base de données ne s'impliquent pas dans les règles métier. Ils sont principalement là pour faire fonctionner les choses. Ils ne pousseront jamais pour les contraintes dans la base de données. Devoir gérer des applications héritées, des intégrations, des migrations, des fusions, des acquisitions, une contrainte db peut être la meilleure solution.
- La surcharge de la base de données peut créer un goulot d'étranglement qui n'est pas facilement résolu en jetant plus de machines sur le problème. Il y a des situations où le langage db ne gère pas certains problèmes de programmation sans un impact majeur sur les performances, vous ne pouvez donc pas prévoir d'utiliser une contrainte pour tout. Stackoverflow a un serveur de base de données car lancer 2 sur un problème est un défi.
- Tests automatisés - ils y arrivent, mais de nombreux développeurs de bases de données sont en retard avec les frameworks IDE/testing.
- Déploiement - plus de choses sur la 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 il existe des données qui violent la contrainte? Fin de la partie, 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 dans un lot.
- Seule l'application/api/service pourra jamais écrire des données dans la base de données, alors pourquoi s'embêter? Cela tient la plupart du temps, c'est pourquoi ce n'est pas courant.
- La gestion des erreurs de base de données est déjà assez difficile sans des centaines de violations de contraintes à gérer si tout se dérobe. La plupart sont heureux d'établir une connexion et d'obtenir le nom de table correct.
De nombreuses équipes de développement ne veulent pas donner trop de contrôle à un développeur db. Vous avez de la chance si vous en obtenez plus d'un, les vacances sont donc très amusantes. Peu d'entre eux nécessitent un contrôle absolu sur le domaine de la base de données et prennent la responsabilité de chaque requête, règle métier, performances, disponibilité, sécurité et quelles données vont à quel RAID. Voici les procédures stockées que vous êtes autorisé à exécuter. S'amuser. Ne pensez même pas à toucher une table.
C'est un problème que j'ai eu du mal avec toute ma carrière (près de 40 ans) et aussi lors de l'écriture de mon SGBD. Une description de mon point final est ici: http://unibase.zenucom.com . Voici donc mes pensées.
- De manière générale, la plupart des contraintes sont mieux gérées dans l'application afin 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.
- Par ailleurs, méfiez-vous de%. Les majorations sont> 100% ou vous faites faillite :)
- 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.
- 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 dans un SGBDR et très utile. La plus grande difficulté consiste à décider de laisser une valeur suspendre si le FK est supprimé ou d'utiliser des lignes dépendantes comme raison de ne pas supprimer l'enregistrement FK.
- Les contraintes dans le monde réel sont généralement plus complexes qu'une restriction de valeur de champ unique.
- Certaines contraintes, même au niveau de l'application, vont à l'encontre de bonnes opérations. Par exemple, une vérification agressive des dates cache des 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 semblent autrement raisonnables.
Plus souvent de nos jours, les gens utilisent un logiciel (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 SQL, libérant ainsi les capacités cérébrales.
Les attentes selon lesquelles les logiciels "fonctionneront" sont souvent irréalistes et ne créent pas les contraintes que ferait un humain.
Pour de meilleurs résultats, créez des tables à l'aide de SQL et ajoutez des contraintes manuellement, mais parfois les gens ne peuvent pas le faire.
Les contraintes de base de données auraient pu être une idée intelligente, mais qu'en est-il d'une utilisation pratique? Prenez votre contrainte de pourcentage. Si vous appliquez cela, votre base de données rejettera volontiers les pourcentages invalides. Et alors? Vous aurez besoin d'une logique métier pour gérer l'exception. Ce qui signifie en fait que la logique métier d'écrire un mauvais pourcentage a déjà échoué ailleurs. Donc en bref: la seule contrainte pratique qui reste est celle que vous voyez (comme PK/FK).