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 tinyint
serait plus approprié) et il n'y a pas de CHECK
contrainte 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
102
sous 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
102
s’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 .