L'intégrité référentielle devrait-elle être appliquée?

Tout d'abord, il est presque impossible de le faire fonctionner correctement. Pour avoir une chance de fonctionner correctement, vous devez envelopper une grande partie des modifications en cascade en tant que transactions, de sorte que vous n'avez pas les choses désynchronisées pendant que vous avez changé une partie de la base de données, mais que vous mettez à jour d'autres qui dépendent de la première. Cela signifie que le code qui devrait être simple et conscient uniquement de la logique métier doit soudainement connaître toutes sortes de problèmes de concurrence.

Deuxièmement, ça marche est presque impossible à espérer-chaque fois que quelqu'un touche à la logique métier, il doit à nouveau traiter ces problèmes de concurrence.

Troisièmement, cela rend l'intégrité référentielle difficile à comprendre-à l'avenir, quand quelqu'un veut en apprendre davantage sur la structure de votre base de données, il devra l'ingénierie inverse hors de votre logique métier. Avec elle dans la base de données, c'est séparé, donc ce que vous devez regarder seulement traite de l'intégrité référentielle, pas toutes sortes de sans rapport avec les questions. Vous avez (par exemple) des chaînes directes de logique montrant ce qu'une modification d'un champ particulier déclenchera. Au moins pour un bon nombre de bases de données, cette logique peut être automatiquement extraite et transformée en documentation assez utile (par exemple, des diagrammes arborescents montrant les dépendances). Extraire le même type d'information de la BLL est plus susceptible d'être un projet assez sérieux.

Il y a certainement quelques points dans l'autre sens, et des raisons de concevoir tout cela par main-l'évolutivité et la performance étant les plus évidentes. Quand/si vous allez dans cette voie, cependant, vous devriez être conscient de ce que vous abandonnez pour obtenir cette performance. Dans certains cas, c'est un compromis valable-mais dans d'autres cas, ce n'est pas le cas, et vous avez besoin d'informations pour prendre une décision motivée.

Les Relations peuvent être maintenues dansune couche logique métier . Sauf si vous pouvez garantir à 100% hors de tout doute que votre BLL est et sera toujours sans bug, alors vous n'avez pas l'intégrité des données. Et vous ne pouvez pas faire cette garantie.

En outre, si une autre application touchera jamais votre base de données, il n'est pas nécessaire de suivre (Lire: réimplémenter, peut-être d'une manière subtilement fausse) les règles de votre BLL. Il pourrait corrompre les données, même si vous avez réussi à être l'un des les 3 programmeurs sur Terre pour écrire du code sans bug.

La base de données, quant à elle, applique les mêmes règles pour tout le monde-et les règles appliquées par la base de données sont beaucoup moins susceptibles d'être négligées lorsque vous mettez à jour, puisque la base de données ne le permettra pas.

Avoir un Écouter à Dan Pritchett, Technical Fellow chez eBay sur la raison pour laquelle certaines constructions de base de données telles que les transactions et l'intégrité référentielle ne sont pas les mandats que les manuels pourraient indiquer qu'ils devraient être... Cela se résume aux types de données, au volume de requêtes et aux exigences métier. Équilibrez-les et cela vous mènera à des solutions pragmatiques, pas à des réponses dogmatiques...

Cependant, nePas supposer que garder des relations dans la BLL protégera votre données. Vous ne pouvez pas garantir que les futurs développeurs n'exposeront pas de nouvelles API qui contournent la BLL pour des raisons de "performance" ou un simple manque de compréhension de votre architecture...

L'hypothèse de performance sur laquelle la question est basée est incorrecte en règle générale. Habituellement, si vous avez besoin que RI soit appliqué, la base de données est l'endroit le plus efficace pour le faire, pas l'application - sinon l'application doit requery plus de données afin de pouvoir valider RI en dehors de la base de données.

En outre, les contraintes RI dans la base de données sont utiles pour l'optimiseur de requêtes afin de rendre les autres requêtes plus efficaces. Les contraintes d'intégrité dans l'application ne peuvent pas d'atteindre cet objectif.

Enfin, le coût du maintien des contraintes d'intégrité dans chaque application est généralement plus coûteux et complexe que de le faire une fois au même endroit.

Beaucoup a déjà été dit sur le fait que la base de données devrait être le dernier endroit pour valider / contrôler vos contraintes (et je ne pouvais pas être plus d'accord)

Si les données sont importantes, votre application ne sera pas la dernière à accéder à la base de données et elle ne sera pas la seule.

Mais il y a un autre fait très important à propos de l'intégrité référentielle (et d'autres contraintes): il documente votre datamodel et rend les dépendances entre les tables explicites.

Jusqu'à la performance est concernée, la définition de FK (ou d'autres contraintes) dans la base de données peut rendre les choses encore plus rapides dans certains cas, car le SGBD peut s'appuyer sur les contraintes et faire des optimisations approriate.

Mais Colonel Ingus, si vous avez le client avec un identifiant dans la session, vous avez déjà sondé la base de données! Le problème est lorsque vous écrivez ensuite votre commande client, mais ne l'attachez pas à un produit parce que vous n'avez pas de problème pour un produit. D'une manière ou d'une autre, vous finirez avec des enregistrements orphelins, tout comme la très grande entreprise pour laquelle je travaille actuellement. Nous avons des clients sans histoire et sans histoire; des clients avec des soldes en circulation qui n'ont jamais rien acheté et les marchandises vendues à des clients qui n'existent pas-des concepts commerciaux intéressants-et cela maintient une équipe de personnel de soutien très frustré dans un emploi à temps plein en essayant de le régler. Il serait beaucoup moins coûteux d'avoir mis RI sur tout et acheté une boîte plus grande pour régler les problèmes de performance perçus.

Ce que paxdiablo et dportas ont dit. Et mes deux cents. Il y a deux autres considérations.

Afin de valider l'intégrité référentielle d'un nouvel insert, vous devez effectuer une sonde dans la base de données pour vérifier que la référence est valide. Vous venez de annuler le gain de performance qui vous a amené à vouloir appliquer l'intégrité dans l'application. Il est en fait plus rapide de laisser le SGBD appliquer l'intégrité référentielle.

Au-delà de cela, considérez le cas où vous avez plus d'un application toutes les données de lecture et d'écriture dans une seule base de données. Si vous appliquez l'intégrité référentielle dans la couche application métier, vous devez vous assurer que toutes les applications fonctionnent correctement. Sinon, une application aberrante pourrait stocker des réfrences non valides, et le problème pourrait apparaître lorsqu'une application différente utiliserait les données. C'est un véritable gâchis. Mieux vaut que le SGBD applique les règles de données pour toutes les applications.

Cela dépend des données, si ses données hautement transactionnelles telles que les transactions commerciales et ce qui n'est pas le cas lorsque des mises à jour fréquentes se produisent, l'application des règles métier dans la base de données est extrêmement importante.. Mais pour tout le reste, l'impact sur les performances peut ne pas en valoir la peine..

Si vous maintenez les relations dans la couche métier, vous pouvez garantir que quelques années plus tard, vous aurez de mauvaises données dans la base de données. La couche d'affaires est le pire endroit possible pour le faire.

De plus, lorsque vous remplacez la couche métier par autre chose, vous devez redéfinir toutes ces choses. Les bases de données survivent souvent à l'application d'origine pour laquelle elles sont écrites depuis de nombreuses années, mettent les bonnes propriétés et contraintes dans la base de données où elles appartiennent.

Que se passe-t-il lorsque vous essayez d'insérer un enregistrement dans la base de données et qu'il échoue à l'intégrité référentielle? Vous obtenez une erreur de la base de données. Ensuite, vous devez changer votre code afin qu'il n'essaie pas d'insérer des données invalides. Pour éviter les erreurs d'intégrité ref, votre code doit savoir quelles sont les données. Par conséquent, l'intégrité référentielle est inutile.

Walter Mitty a déclaré: "afin de valider l'intégrité référentielle d'un nouvel insert, vous devez faire une sonde dans la base de données pour vérifier que le de référence est valide." Soupir... c'est un non-sens complet. Si j'ai un objet client dans la session (c'est la mémoire, alias RAM pour certains d'entre vous), je connais L'ID du client et je peux l'utiliser pour insérer un objet SalesOrder. Il n'est pas nécessaire de rechercher le client.

Je suis sur un système maintenant avec une intégrité référentielle étroite et Hibernate enroulé autour de lui avec ses tenticles bruts. C'est le système le plus lent que j'ai jamais vu. Je ne l'ai pas conçu et si je l'avais, ce serait plusieurs fois plus rapide et plus facile à maintenir. Hibernate craint.