Devrais-je définir les relations entre les tables de la base de données ou juste en code?

60

D'après mon expérience, de nombreux projets que j'ai lus dans le passé ne contenaient pas de définition de relation dans la base de données, ils ne les définissaient que dans le code source. Je me demande donc quels sont les avantages / inconvénients de la définition des relations entre les tables de la base de données et du code source? Et la question plus générale concerne d’autres fonctionnalités avancées des bases de données modernes telles que la cascade, les déclencheurs, les procédures… Il ya quelques points dans mes pensées:

Dans la base de données:

Corrigez les données de la conception. Prévenez les erreurs d'application pouvant générer des données non valides.
Réduisez l'aller-retour réseau vers l'application lors de l'insertion / de la mise à jour de données, car l'application doit effectuer davantage de requêtes pour vérifier l'intégrité des données.

En code source:

Plus flexible.
Il est préférable d’effectuer une mise à l’échelle sur plusieurs bases de données, car la relation peut parfois être cross-database.
Plus de contrôle sur l'intégrité des données. La base de données n'a pas à vérifier chaque fois que l'application modifie des données (la complexité peut être O (n) ou O (n log n) (?)). Au lieu de cela, il est délégué à l'application. Et je pense que la gestion de l'intégrité des données dans l'application entraînera plus de messages d'erreur détaillés que l'utilisation de la base de données. Exemple: lorsque vous créez un serveur d'API, si vous définissez les relations dans la base de données et que quelque chose ne va pas (l'entité référencée n'existe pas), vous obtiendrez une exception SQL avec un message. Le moyen le plus simple consiste à renvoyer 500 informations au client en signalant une "erreur de serveur interne" et le client n’a aucune idée de ce qui ne va pas. Ou le serveur peut analyser le message pour déterminer ce qui ne va pas, ce qui est une manière laide et sujette aux erreurs, à mon avis. Si vous laissez l'application gérer cela,

Y a-t-il autre chose?

Edit: comme le fait remarquer Kilian, mon point sur les performances et l’intégrité des données est très erroné. Donc j'ai édité pour corriger mon point là. Je comprends tout à fait que laisser la base de données la gérer sera une approche plus efficace et robuste. S'il vous plaît vérifier la question mise à jour et donner quelques idées à ce sujet.

Edit: merci à tous. Les réponses que j'ai reçues indiquent toutes que les contraintes / relations doivent être définies dans la base de données. :) J'ai une autre question, car elle est tout à fait hors de portée de cette question. Je viens de l'afficher sous la forme d'une question distincte: Gestion des erreurs de base de données pour le serveur d'API . S'il vous plaît laissez quelques idées.

— Yoshi
source

4

"car l’application doit faire plus de requêtes pour vérifier l’intégrité des données." Pas nécessairement. Si la base de données est entièrement sous le contrôle de votre application, des vérifications supplémentaires de l'intégrité des données peuvent constituer une programmation trop défensive. Vous n'avez pas nécessairement besoin d'eux. testez simplement votre application pour vous assurer qu'elle n'apporte que des modifications valides à la base de données.

9

Il y a une chose que vous ne devriez jamais oublier: à moins que toutes les personnes impliquées écrivent un logiciel parfait, si les vérifications sont dans le logiciel, l'une de ces vérifications échouera et entraînerait la non-application des contraintes. Ce n'est pas une question de savoir si, mais de quand. Cela rend difficile la reproduction des erreurs et de longues heures de traitement des données pour respecter à nouveau les contraintes imposées par le logiciel.

— Dabu

10

Quelque chose qui mérite d'être mentionné ... une fois que vous avez introduit des problèmes d'intégrité dans votre base de données, il est devenu un parent pour ouvrir la boîte de Pandore. Réintroduire l'intégrité dans une base de données contenant des anomalies est un cauchemar. Garder des contrôles stricts sur votre base de données peut être un problème, mais cela vous évitera beaucoup de souffrances à long terme.

— 2016

3

En code source: vous finissez par écrire la majeure partie d'une base de données.

— Blrfl

7

Une fois, j’ai posé une question similaire à un programmeur très talentueux, me dit-il "C’est comme des freins sur une voiture. L’important n’est pas de ralentir la voiture, mais de la rendre plus sûre et plus rapide." Bien sûr, il est possible de fonctionner sans contraintes, mais si de mauvaises données parviennent d’une manière ou d’une autre, cela peut causer un grave accident

— mercurial

70

TL; DR: les contraintes de relation doivent figurer dans la base de données.

Votre application n'est pas assez grosse.

Vous avez raison de dire que l’application de relations entre bases de données peut nécessiter leur application dans l’application.

Je tiens toutefois à souligner que vous devez d’abord consulter la documentation du logiciel de base de données que vous utilisez, puis consulter les offres de produits existants. Par exemple, il existe des offres de regroupement en plus de Postgres et de MySQL.

Et même si vous avez besoin d' une validation dans l'application, ne jetez pas le bébé avec l'eau du bain . Après tout, moins vous avez à faire, mieux vous vous portez.

Enfin, si vous vous inquiétez des problèmes d'évolutivité futurs, je crains que votre application ne soit soumise à des modifications importantes avant de pouvoir de toute façon évoluer. En règle générale, chaque fois que vous développez 10x, vous devez repenser la conception ... ne perdez donc pas trop d'argent pour ne pas anticiper les problèmes d'évolutivité, mais utilisez plutôt l'argent pour atteindre le point où vous en êtes confronté.

Votre application n'est pas assez correcte.

Quelle est la probabilité que la base de données que vous utilisez ait une implémentation incorrecte du contrôle par rapport à la probabilité que votre application ait une implémentation incorrecte du contrôle?

Et lequel modifiez-vous le plus souvent?

Je parie que la base de données est correcte, à tout moment .

Vos développeurs ne pensent pas assez distribués.

Réduisez l'aller-retour réseau vers l'application lorsque vous insérez / mettez à jour des données, car l'application doit effectuer plus de requêtes pour vérifier l'intégrité des données.

Drapeau rouge ! ¹

Si vous pensez:

vérifier si le dossier existe
sinon, insérez l'enregistrement

alors vous avez échoué au problème le plus élémentaire de la simultanéité: un autre processus / fil pourrait ajouter l'enregistrement au fur et à mesure.

Si vous pensez:

vérifier si le dossier existe
sinon, insérez l'enregistrement
vérifier si l'enregistrement a été inséré en double

alors vous avez échoué à prendre en compte MVCC: la vue de la base de données que vous avez est un instantané au moment où votre transaction a commencé; il ne montre pas toutes les mises à jour en cours et peut-être même pas validées.

Le maintien des contraintes sur plusieurs sessions est un problème très difficile, soyez heureux qu'il soit résolu dans votre base de données.

¹ Sauf si votre base de données implémente correctement la propriété Serializable; mais peu le font réellement.

Dernier:

Et je pense que gérer l’intégrité des données dans l’application laissera plus de messages d’erreur détaillés que d’utiliser une base de données. Exemple: lorsque vous créez un serveur API. Si vous définissez des relations dans la base de données et que quelque chose ne va pas (par exemple, l'entité référencée n'existe pas), vous obtiendrez une exception SQL avec un message.

Ne pas analyser les messages d'erreur . Si vous utilisez une base de données de type production, les erreurs structurées doivent être renvoyées. Vous aurez au moins un code d'erreur pour indiquer ce qui peut ne pas être correct. Sur la base de ce code, vous pouvez créer un message d'erreur approprié.

Notez que la plupart du temps, le code est suffisant: si vous avez un code d'erreur indiquant qu'une clé étrangère référencée n'existe pas, il est probable que cette table ne comporte qu'une seule clé étrangère. Vous savez donc dans le code quel est le problème. .

En outre, et soyons honnêtes ici, la plupart du temps, vous ne gérerez pas les erreurs de façon aussi élégante. Tout simplement parce qu'ils sont nombreux et que vous ne pourrez pas en rendre compte pour tous ...

... qui rejoint juste le point correct ci-dessus. Chaque fois que vous voyez une "500: Internal Server Error" parce qu'une contrainte de base de données s'est déclenchée et qu'elle n'a pas été gérée, cela signifie que la base de données vous a sauvegardé, car vous avez simplement oublié de la gérer dans le code.

— Matthieu M.
source

3

Haha, vous avez écrit ceci alors que je rédigeais mon commentaire, soulignant ironiquement ce que nous disons tous les deux. Je suis tout à fait d’accord: vous ne pouvez même pas faire preuve d’intégrité ou de contraintes dans du code non DB. Les transactions ne peuvent pas voir les résultats des autres tant qu'elles ne sont pas validées (et peut-être même pas). Vous pouvez avoir l’illusion d’intégrité, mais cela est sujet à des problèmes de timing ou d’évolutivité graves dus aux verrous. Seule la base de données peut le faire correctement.

— LoztInSpace

8

Tous les bons points. Une autre est que les relations dans une base de données sont auto-documentées. Si vous avez déjà eu à désosser une base de données dont les relations n'étaient définies que dans le code qui l'interroge, vous détesterez tous ceux qui le font de cette façon.

— Kat

1

@ Kat11: C'est vrai. L'auto-description présente également l'avantage que les outils peuvent facilement comprendre les données et les exploiter, ce qui peut parfois être utile.

— Matthieu M.

1

Votre argument à propos de MVCC n'est pas précis dans les bases de données qui implémentent correctement l'isolation SERIALIZABLE (les versions modernes de PostgreSQL le font, par exemple - bien que de nombreux principaux SGBDR ne l'aient pas). Dans une telle base de données, même la première approche, naïve, fonctionnerait correctement - si les écritures étaient en conflit, elles seraient annulées en tant qu'échec de la sérialisation.

— James_pic

1

Dans les bases de données qui implémentent correctement SERIALIZABLE, si vous prenez toutes les transactions validées avec succès, il existe un ordre (qui peut ne pas être identique à un ordre d'horloge murale), de sorte que si vous les avez toutes exécutées en série (sans simultanéité) dans cet ordre, tous les résultats auraient été exactement les mêmes. C'est délicat à comprendre, et les spécifications SQL sont suffisamment vagues pour que vous puissiez vous convaincre qu'il est correct d'autoriser l'écriture asymétrique au niveau SERIALIZABLE. Par conséquent, de nombreux fournisseurs de bases de données traitent SERIALIZABLE comme une SNAPSHOT ISOLATION (je vous regarde Oracle).

— James_pic

118

La base de données n'a pas à vérifier l'intégrité des données chaque fois que l'application modifie des données.

C'est un point profondément erroné. Les bases de données ont été créées précisément dans ce but. Si vous avez besoin de contrôles d'intégrité des données (et si vous pensez ne pas en avoir besoin, vous vous trompez probablement), laisser la base de données les gérer est certainement plus efficace et moins sujet aux erreurs que de le faire dans la logique d'application.

— Kilian Foth
source

5

@ dan1111 Je ne comprends pas votre commentaire ... vous dites: des contraintes simples sont imposées par la base de données, elles ne sont donc pas un problème pour le code de l'application, des contraintes plus complexes sont trop difficiles à implémenter, alors abandonnez-les? Ou dites-vous que l'implémentation de contraintes complexes à l'aide de déclencheurs de base de données (et d'un mécanisme similaire) est trop complexe et qu'il est donc préférable de les implémenter dans le code de l'application?

— Bakuriu

47

Vous ne pouvez même pas faire intégrité ou des contraintes en code non DB. Les transactions ne peuvent pas voir les résultats des autres tant qu'elles ne sont pas validées (et peut-être même pas). Vous pouvez avoir l’illusion d’intégrité, mais cela est sujet à des problèmes de timing ou d’évolutivité graves dus aux verrous. Seule la base de données peut le faire correctement.

— LoztInSpace

17

De manière anecdotique, pour faire suite au commentaire de @ LoztInSpace, j'ai déjà travaillé pour une entreprise (terrible) où l'une de ces tables était configurée de telle sorte qu'au lieu de laisser la base de données incrémenter automatiquement l'ID, l'application prenait l'ID des dernières lignes, ajouté un et utilisé comme nouvel ID. Malheureusement, des identifiants en double ont été introduits environ une fois par semaine, ce qui a pour effet de bloquer

— complètement

9

@ dan1111 Vous n'écrivez jamais de bugs dans l'application, n'est-ce pas?

— user253751

4

@DavidPacker Je pourrais être d' accord, mais une fois que vous avez plusieurs clients accédant à la base de données, vous pouvez seulement appliquer des contraintes dans la base de données. À moins que vous ne commenciez à verrouiller les tables en gros plutôt que par rangées, avec les performances qui en résultent.

— Iker

51

Les contraintes doivent se trouver dans votre base de données, car (avec la meilleure volonté du monde), votre application ne sera pas la seule chose à accéder à cette base de données.

À un moment donné, il faudra peut-être installer un correctif scripté dans la base de données ou migrer des données d'une table à une autre lors du déploiement.

De plus, vous pouvez avoir d’autres exigences, par exemple "Le gros client X a vraiment besoin de cette feuille de données Excel importée dans notre base de données d’applications cet après-midi", où vous n’aurez pas le loisir d’adapter le code de votre application au moment où un script SQL corrompu le fera. à l'heure.

C’est là que l’intégrité au niveau de la base de données sauvera votre bacon.

En outre, décrivez le développeur qui assume votre rôle dans cette société après votre départ et qui est ensuite chargé de modifier la base de données.

Vous haïra-t-il s'il n'y a pas de contrainte FK dans la base de données pour qu'il puisse dire quelles relations a une table avant de la modifier? ( Indice, la réponse est oui )

— Paddy
source

33

Oh, frere. Je ne peux pas vous dire combien de fois j'ai dû expliquer aux gens qu'une base de données avait plus d'un client! Même si, à l' heure actuelle, il n'y a qu'un seul client et qu'une seule avenue pour que les données pénètrent dans le système, la conception de votre application et de votre schéma en fonction de cette hypothèse est le meilleur moyen pour Future Yoshi de haïr Past Yoshi.

— Greg Burghardt

9

@nikonyrh je ne ferais pas cela. Les contraintes sont là pour que les applications puissent s'appuyer sur des données cohérentes. Désactiver FK 'juste pour l'introduire' est une folie.

— Paddy

5

D'accord. De même, même si votre application est le seul client, vous pouvez utiliser différentes versions de votre application pour tenter d'appliquer des contraintes légèrement différentes. D'habitude, l'hilarité s'ensuit (enfin, pas vraiment. Cela ressemble plus à du "chaos et de la frustration totale" qu'à "l'hilarité").

— Iker

5

Je peux absolument en témoigner. Dans mon cas, j'étais bloqué sur MyISAM, qui ne prend pas en charge les clés étrangères. Je me suis donc retrouvé avec 250 Go de données dont l'intégrité était garantie par l'application. Le chaos s'est ensuivi lorsqu'il a fallu commencer à élaguer les données pour réduire l'arriéré à une taille plus gérable, et lorsqu'il est devenu évident que l'application elle-même ne serait pas en mesure de gérer cela. Je ne sais pas pourquoi j'utilise le passé; cela se produit encore maintenant et le problème (deux ans plus tard) n'a toujours pas été résolu. * sniff *

— Les courses de légèreté avec Monica Le

1

Je dirais qu'une base de code correcte devrait faciliter l'écriture d'un script unique en utilisant la couche de persistance de votre application au moins aussi rapidement que l'écriture de code SQL brut. La «modification du code de votre application» ne devrait jamais être nécessaire pour des scripts uniques.

— Jonathan Cast

17

Vous devriez avoir des relations dans la base de données.

Comme l’indique l’autre réponse, les performances de la vérification des contraintes seront bien meilleures dans cette base de données que dans votre application. La vérification des contraintes de base de données est l’un des atouts des bases de données.

Si vous avez besoin d'une flexibilité supplémentaire - par exemple, vos références croisées de bases de données notées -, vous pouvez supprimer les contraintes de manière délibérée et avec considération. La cohérence dans votre base de données signifie que vous avez la possibilité de modifier ces contraintes et la certitude de l’intégrité référentielle.

— Kirk Broadhurst
source

1

Vrai. J'aurais dû dire que les performances de la vérification des contraintes seront mieux gérées dans la base de données que dans l'application.

— Kirk Broadhurst

13

Nous ne vivons plus dans un seul back-end <-> un seul monde front-end.
La plupart des solutions impliquent un front-end web, un front-end mobile, un front-end par lots et un front-end pour iPad, etc.
Les moteurs de base de données disposent déjà de milliers de lignes de code testées optimisées pour appliquer l'intégrité référentielle.

Pouvez-vous vraiment vous permettre d'écrire et de tester du code renforçant l'intégrité référentielle lorsque vous avez du code de résolution de problèmes de domaine à écrire?

— Tulains Córdova
source

2

"Nous ne vivons plus dans un seul back-end <-> un seul monde front-end." Avons-nous jamais? Il y a quelques années, j'ai travaillé sur un système de base de données contenant des programmes écrits dans au moins deux douzaines de langues différentes. Certains programmes ont vu le jour dans les années 1970.

— Mike Sherrill 'Cat Recall'

2

Si vous ne validez pas l'intégrité, les contraintes, les relations, etc. des données au niveau de la base de données, il est beaucoup plus facile pour quiconque disposant d'un accès à la base de données de production (via tout autre client, y compris un outil d'accès à la base de données) de corrompre vos données.

Il est recommandé d'appliquer une intégrité des données aussi stricte que possible au niveau de la base de données. Croyez-moi, cela vous épargnera d'énormes maux de tête au fil du temps dans tout système non trivial. Si vous y réfléchissez bien, vous constaterez également plus rapidement les erreurs de logique d’application ou les erreurs d’exigences commerciales et les incohérences.

En outre, concevez votre base de données de la manière la plus normalisée et la plus atomique possible. Pas de tables "Dieu". Consacrez beaucoup d'efforts à la conception de votre base de données pour qu'elle soit aussi simple que possible, idéalement avec de nombreuses petites tables très bien définies individuellement, avec une responsabilité unique et soigneusement validées sur toutes les colonnes. La base de données est le dernier gardien de l'intégrité de vos données. Il représente le donjon du château.

— Brad Thomas
source

1

La plupart des gens disent essentiellement "oui, en général , vous définissez toujours les relations dans la base de données". Mais si les disciplines en informatique étaient si faciles, on nous appellerait "Lecteurs de logiciels" au lieu de "Ingénieurs". Je conviens en fait que les contraintes devraient figurer dans la base de données, à moins qu’il n’y ait une bonne raison de ne pas le faire , alors permettez-moi de donner quelques raisons qui pourraient être considérées comme bonnes dans certaines situations:

Dupliquer le code

Parfois, une certaine quantité de fonctionnalités pouvant être gérées par la base de données existe naturellement dans le code de l'application. Si l'ajout de contraintes de type base de données à la base de données est redondant, il peut être préférable de ne pas dupliquer la fonctionnalité, car vous enfreignez les principes de DRY et vous risquez d'empêcher la synchronisation de la base de données et du code de l'application.

Effort

Si votre base de données fait déjà ce qu’elle doit faire sans utiliser de fonctionnalités avancées, vous voudrez peut-être évaluer où votre temps, votre argent et vos efforts doivent être placés. Si l'ajout de contraintes empêche une défaillance catastrophique et permet ainsi à votre entreprise d'économiser beaucoup d'argent, cela en vaut probablement la peine. Si vous ajoutez des contraintes qui devraient tenir, mais que vous avez déjà la garantie de ne jamais être violées, vous perdez du temps et polluez votre base de code. Garanti est le mot clé ici.

Efficacité

Ce n'est généralement pas une bonne raison, mais dans certains cas, vous pouvez avoir une certaine exigence de performance. Si le code d'application peut implémenter certaines fonctionnalités plus rapidement que la base de données et que vous avez besoin de performances supplémentaires, vous devrez peut-être implémenter la fonctionnalité dans le code d'application.

Contrôle

Un peu lié à l'efficacité. Parfois, vous avez besoin d'un contrôle extrêmement fin sur la manière dont une fonctionnalité est mise en œuvre, et parfois, le traitement de la base de données la cache derrière une boîte noire que vous devez ouvrir.

Points de fermeture

Les bases de données sont écrites en code. Ils ne font rien de magique que vous ne pouvez pas faire dans votre propre code.
Rien n'est gratuit. Les contraintes, les relations, etc. utilisent toutes des cycles de calcul.
Dans le monde NoSQL, les gens s'entendent bien sans les fonctions relationnelles traditionnelles. Dans MongoDB, par exemple, la structure des documents JSON est suffisante pour prendre en charge une base de données complète.
L'utilisation aveugle et ignorante de fonctions de base de données avancées ne garantit aucun avantage. Vous pourriez accidentellement faire quelque chose travailler que pour le casser plus tard.
Vous avez posé une question très générale sans énumérer des exigences ou des contraintes spécifiques. La vraie réponse à votre question est "ça dépend".
Vous n'avez pas précisé s'il s'agissait d'un problème à l'échelle de l'entreprise. D'autres réponses traitent d'éléments tels que les clients et l'intégrité des données, mais parfois ces éléments ne sont pas importants.
Je suppose que vous parlez d'une base de données relationnelle SQL traditionnelle.
Mon point de vue vient d'avoir abandonné l'utilisation de tonnes de contraintes et de clés étrangères dans de petits projets (jusqu'à 50 tables) et de ne pas remarquer d'inconvénients .

La dernière chose que je dirai, c'est que vous saurez si vous ne devriez pas placer les fonctionnalités dans la base de données. Si vous n'êtes pas sûr, vous ferez probablement mieux d'utiliser les fonctionnalités de la base de données, car elles fonctionnent généralement très bien.

— parker.sikand
source

1

Si les gens votent pour des réponses bien pensées parce que cela ne correspond pas à leur dogme, le SE StackExchange devient un endroit pire.

— Carl Leth

5

La prémisse de cette réponse selon laquelle il peut arriver que vous laissiez des contraintes en dehors de la base de données est valide, mais l'explication est médiocre et trompeuse. Bien que je convienne que la base de données n'est pas le meilleur endroit pour certaines contraintes, aucune base de données relationnelle ne devrait disparaître sans la clé de base et les contraintes d'intégrité référentielle . Aucun . Il n'y a aucune exception à cela. Chaque base de données aura besoin de clés primaires et la grande majorité aura besoin de clés étrangères. Celles-ci devraient toujours être appliquées par la base de données, même si elle duplique la logique. C'est pour cette raison que j'ai voté contre.

— jpmc26

1

"Les bases de données sont écrites en code. Elles ne font rien de magique, vous ne pouvez pas le faire dans votre propre code." , non, vous ne pouvez pas appliquer l’intégrité référentielle dans le code de l’application (et si vous n’avez pas besoin de l’appliquer, pourquoi utilisez-vous un serveur de base de données?). Il ne s'agit pas de savoir ce que le code peut faire, mais de savoir où il peut être fait.

— Hyde

0

Comme toujours, les réponses sont nombreuses. Pour moi, j'ai trouvé une règle simple (cela ne fonctionne que pour une approche centrée sur le modèle). D'habitude, je me concentre uniquement sur les différentes couches d'applications.

Si le modèle comprend plusieurs entités et qu'il existe des dépendances entre elles, la couche de persistance doit refléter ces dépendances avec ses possibilités. Donc, si vous utilisez un SGBDR, vous devez également utiliser des clés étrangères. La raison est simple. De cette façon, les données sont toujours valables sur le plan de la structure.

Toute instance effectuant un travail sur cette couche de persistance peut compter sur elle. Je suppose que vous encapsulez cette couche via une interface (service). Donc, voici le point où le design se termine et le monde réel commence.

En examinant vos points, en particulier les références inter-bases de données . Dans ce cas, oui, il ne devrait pas y avoir de référence implémentée dans le SGBDR, mais dans le service. Mais avant de suivre cette voie, ne vaudrait-il pas mieux en tenir compte lors de la conception?

Cela signifie, si je le sais déjà, qu'il y a des pièces qui doivent être stockées dans une base de données différente, alors je peux les mettre déjà là et les définir en tant que modèle séparé. Droite?

Vous indiquez également que la mise en œuvre de cette méthode dans le code est plus flexible . D'accord, mais cela ne semble-t-il pas être un dessin incomplet? Demandez-vous, pourquoi avez-vous besoin de plus de flexibilité?

Le problème de performances, dû aux contrôles d'intégrité dans la base de données, n'est pas réel. Le SGBDR peut vérifier ces choses beaucoup plus rapidement que toute implémentation de votre part. Pourquoi? Eh bien, vous devez faire face à la perturbation des médias, pas le SGBDR. Et il peut optimiser ces contrôles en utilisant ses statistiques, etc.

Donc, vous voyez, tout revient à la conception. Bien sûr, vous pouvez le dire maintenant, mais que se passe-t-il si une exigence inconnue apparaît, un changeur de jeu? Oui, cela pourrait arriver, mais de tels changements devraient être conçus et planifiés, etc. ; o)

— DHN
source

0

Vous avez de très bonnes réponses mais quelques points supplémentaires

L'intégrité des données est ce qu'une base de données est conçue pour faire

Faire une simultanéité appropriée avec une suppression semblable à FK au niveau de l'application serait horrible

L'expertise en intégrité des données est avec un DBA

Au niveau du programme, vous insérez, mettez à jour, mettez à jour en bloc, insérez en bloc, effacez en bloc ...
Client léger, client lourd, client mobile ...
L'intégrité des données n'est pas l'expertise d'un programmeur - beaucoup de code en double et quelqu'un gâcher ça monte

Supposons que vous soyez piraté - vous avez des problèmes de toute façon, mais un pirate informatique peut faire beaucoup de dégâts via un petit trou s'il n'y a pas de protection d'intégrité dans la base de données

Vous devrez peut-être manipuler des données directement via SQL ou TSQL
Personne ne se souviendra de toutes les règles de données

— paparazzo
source

0

Votre question n'a pas de sens: si vous pouvez modifier la base de données, c'est du code, si vous ne pouvez pas modifier la base de données, vous devrez créer vos contraintes ailleurs.

Une base de données que vous pouvez modifier contient autant de code qu'une ligne de ruby, javascript, c # ou ada.

La question de savoir où placer une contrainte dans votre système devrait se résumer à la fiabilité, au coût et à la facilité de développement.

— jmoreno
source

0

Il y a des tonnes de bonnes réponses ici. J'ajouterai que si vous avez une application écrite dans la langue Y, vous pouvez créer du code similaire à une contrainte de base de données dans Y. Et si quelqu'un souhaite accéder à votre base de données à l'aide de la langue Z, vous devrez à nouveau écrire le même code. Dieu vous aide si les implémentations ne sont pas exactement les mêmes. Ou lorsqu'un utilisateur professionnel averti se connecte à votre base de données à l'aide de Microsoft Access.

Mon expérience me dit que lorsque les gens ne veulent pas utiliser les contraintes de base de données, c'est parce qu'ils essaient de faire quelque chose de mal. Par exemple, ils essaient de charger en bloc des données et veulent laisser les colonnes non NULL, pendant un moment. Ils ont l'intention de "réparer cela plus tard", car la situation qui a rendu critique la contrainte non nulle "ne peut pas se produire dans ce cas." Un autre exemple pourrait être quand ils essaient de combiner deux types de données différents dans la même table.

Les personnes plus expérimentées prendront du recul et trouveront une solution qui n'impliquera pas de tenter de contourner une contrainte. La solution pourrait tout simplement être que la contrainte ne convient plus car l'activité a changé, bien sûr.

— Tony Ennis
source