Je me souviens avoir entendu Joel Spolsky mentionner dans le podcast 014 qu'il avait à peine utilisé une clé étrangère (si je me souviens bien). Cependant, ils me semblent assez vitaux pour éviter la duplication et les problèmes ultérieurs d'intégrité des données dans votre base de données.

Les gens ont-ils des raisons solides pour expliquer pourquoi (pour éviter une discussion conforme aux principes de Stack Overflow)?

Edit: "Je n'ai pas encore de raison de créer une clé étrangère, donc cela pourrait être ma première raison d'en créer une."

Raisons d'utiliser des clés étrangères:

• vous n'obtiendrez pas de lignes orphelines
• vous pouvez obtenir un bon comportement "en cas de suppression de cascade", en nettoyant automatiquement les tables
• connaître les relations entre les tables de la base de données aide l'Optimizer à planifier vos requêtes pour une exécution plus efficace, car il est capable d'obtenir de meilleures estimations sur la cardinalité de jointure.
• Les FK donnent un assez gros indice sur les statistiques les plus importantes à collecter sur la base de données, ce qui conduit à son tour à de meilleures performances
• ils permettent toutes sortes de support généré automatiquement - les ORM peuvent se générer eux-mêmes, les outils de visualisation pourront créer de belles dispositions de schéma pour vous, etc.
• une personne nouvelle dans le projet entrera plus rapidement dans le flux des choses car sinon les relations implicites sont explicitement documentées

Raisons de ne pas utiliser de clés étrangères:

• vous faites travailler la base de données supplémentaire sur chaque opération CRUD car elle doit vérifier la cohérence FK. Cela peut être un gros coût si vous avez beaucoup de désabonnement
• en imposant des relations, les FK spécifient un ordre dans lequel vous devez ajouter / supprimer des éléments, ce qui peut conduire au refus de la base de données de faire ce que vous voulez. (Certes, dans de tels cas, ce que vous essayez de faire est de créer une ligne orpheline, et ce n'est généralement pas une bonne chose). Cela est particulièrement douloureux lorsque vous effectuez de grandes mises à jour par lots et que vous chargez une table avant une autre, la deuxième table créant un état cohérent (mais devriez-vous faire ce genre de chose s'il y a une possibilité que le deuxième chargement échoue et que votre est maintenant incohérente?).
• parfois vous savez à l'avance que vos données vont être sales, vous l'acceptez et vous voulez que la base de données l'accepte
• vous êtes juste paresseux :-)

Je pense (je ne suis pas certain!) Que la plupart des bases de données établies fournissent un moyen de spécifier une clé étrangère qui n'est pas appliquée, et est simplement un peu de métadonnées. Étant donné que la non-application efface toutes les raisons de ne pas utiliser les FK, vous devriez probablement suivre cette voie si l'une des raisons de la deuxième section s'applique.

C'est une question d'éducation. Si, quelque part dans votre carrière éducative ou professionnelle, vous avez passé du temps à alimenter et à prendre soin de bases de données (ou à travailler en étroite collaboration avec des personnes talentueuses qui l'ont fait), les principes fondamentaux des entités et des relations sont bien ancrés dans votre processus de réflexion. Parmi ces rudiments se trouve comment / quand / pourquoi spécifier des clés dans votre base de données (primaire, étrangère et peut-être alternative). C'est une seconde nature.

Si, cependant, vous n'avez pas eu une telle expérience approfondie ou positive dans votre passé avec les efforts liés au SGBDR, alors vous n'avez probablement pas été exposé à de telles informations. Ou peut-être que votre passé inclut une immersion dans un environnement qui était vociférément anti-base de données (par exemple, "ces DBA sont des idiots - nous sommes peu, nous avons choisi quelques slingers de code java / c # pour sauver la journée"), auquel cas vous pourriez être opposé avec véhémence aux babillages obscurs de certains dweeb vous disant que les FK (et les contraintes qu'ils peuvent impliquer) sont vraiment importants si vous voulez juste écouter.

Quand ils étaient enfants, presque tout le monde a appris qu'il était important de se brosser les dents. Pouvez-vous vous en passer? Bien sûr, mais quelque part sur la ligne, vous aurez moins de dents disponibles que si vous vous étiez brossé après chaque repas. Si les mamans et les papas étaient suffisamment responsables pour couvrir la conception de la base de données ainsi que l'hygiène buccale, nous n'aurions pas cette conversation. :-)

Je suis sûr qu'il existe de nombreuses applications où vous pouvez vous en tirer, mais ce n'est pas la meilleure idée. Vous ne pouvez pas toujours compter sur votre application pour gérer correctement votre base de données, et franchement, la gestion de la base de données ne devrait pas être très préoccupante pour votre application.

Si vous utilisez une base de données relationnelle, il semble que vous devriez y définir des relations . Malheureusement, cette attitude (vous n'avez pas besoin de clés étrangères) semble être adoptée par de nombreux développeurs d'applications qui préfèrent ne pas être gênés par des choses stupides comme l'intégrité des données (mais doivent le faire parce que leurs entreprises n'ont pas de développeurs de bases de données dédiés). Habituellement, dans les bases de données regroupées par ces types, vous avez la chance de ne disposer que de clés primaires;)

Les clés étrangères sont essentielles à tout modèle de base de données relationnelle.

Je les utilise toujours, mais je crée des bases de données pour les systèmes financiers. La base de données est la partie critique de l'application. Si les données d'une base de données financières ne sont pas totalement exactes, peu importe l'effort que vous consacrez à votre code / conception frontale. Vous perdez juste votre temps.

Il y a aussi le fait que plusieurs systèmes doivent généralement s'interfacer directement avec la base de données - d'autres systèmes qui lisent simplement les données (Crystal Reports) aux systèmes qui insèrent des données (pas nécessairement en utilisant une API que j'ai conçue; elle peut être écrite par un têtu (qui vient de découvrir VBScript et qui a le mot de passe SA pour la boîte SQL). Si la base de données n'est pas aussi idiote qu'elle peut l'être, eh bien - bye bye base de données.

Si vos données sont importantes, alors oui, utilisez des clés étrangères, créez une suite de procédures stockées pour interagir avec les données et créez la base de données la plus robuste possible. Si vos données ne sont pas importantes, pourquoi créez-vous d'abord une base de données?

Mise à jour : j'utilise toujours des clés étrangères maintenant. Ma réponse à l'objection "ils ont compliqué les tests" est "écrivez vos tests unitaires pour qu'ils n'aient pas du tout besoin de la base de données. Tous les tests qui utilisent la base de données devraient l'utiliser correctement, et cela inclut les clés étrangères. Si la configuration est pénible, trouver un moyen moins douloureux de faire la configuration. "

Les clés étrangères compliquent les tests automatisés

Supposons que vous utilisez des clés étrangères. Vous écrivez un test automatisé qui dit "lorsque je mets à jour un compte financier, il devrait enregistrer un enregistrement de la transaction". Dans ce test, vous n'êtes concerné que par deux tableaux: accountset transactions.

Cependant, accountsa une clé étrangère vers contracts, et contractsa un fk vers clients, et clientsa un fk vers cities, et citiesa un fk vers states.

Maintenant, la base de données ne vous permettra pas d'exécuter votre test sans configurer les données dans quatre tables qui ne sont pas liées à votre test .

Il y a au moins deux perspectives possibles à ce sujet:

• "C'est une bonne chose: votre test doit être réaliste et ces contraintes de données existeront en production."
• "C'est une mauvaise chose: vous devriez être en mesure de tester des éléments unitaires du système sans impliquer d'autres éléments. Vous pouvez ajouter des tests d'intégration pour le système dans son ensemble."

Il peut également être possible de désactiver temporairement les vérifications de clé étrangère lors de l'exécution des tests. MySQL, au moins, le supporte .

"Ils peuvent rendre la suppression des enregistrements plus lourde - vous ne pouvez pas supprimer l'enregistrement" maître "où il y a des enregistrements dans d'autres tables où les clés étrangères violeraient cette contrainte."

Il est important de se rappeler que la norme SQL définit les actions qui sont prises lorsqu'une clé étrangère est supprimée ou mise à jour. Ceux que je connais sont:

• ON DELETE RESTRICT- Empêche la suppression de toutes les lignes de l'autre table contenant des clés dans cette colonne. C'est ce que Ken Ray a décrit ci-dessus.
• ON DELETE CASCADE - Si une ligne de l'autre table est supprimée, supprimez toutes les lignes de cette table qui la référencent.
• ON DELETE SET DEFAULT - Si une ligne de l'autre table est supprimée, définissez toutes les clés étrangères faisant référence à la valeur par défaut de la colonne.
• ON DELETE SET NULL - Si une ligne de l'autre table est supprimée, définissez toutes les clés étrangères qui y font référence dans cette table sur null.
• ON DELETE NO ACTION- Cette clé étrangère indique uniquement qu'il s'agit d'une clé étrangère; à savoir pour une utilisation dans les mappeurs OR.

Ces mêmes actions s'appliquent également à ON UPDATE.

La valeur par défaut semble dépendre de sql serveur que vous utilisez.

@imphasing - c'est exactement le genre de mentalité qui provoque des cauchemars de maintenance.

Pourquoi oh pourquoi ignoreriez-vous l'intégrité référentielle déclarative, où les données peuvent être garanties d'être au moins cohérentes, en faveur de ce que l'on appelle l '"application logicielle", qui est au mieux une faible mesure préventive.

Il y a une bonne raison de ne pas les utiliser: si vous ne comprenez pas leur rôle ou comment les utiliser.

Dans de mauvaises situations, les contraintes de clés étrangères peuvent entraîner la réplication des accidents en cascade. Si quelqu'un supprime le mauvais enregistrement, le défaire peut devenir une tâche gigantesque.

En outre, à l'inverse, lorsque vous devez supprimer quelque chose, si elles sont mal conçues, les contraintes peuvent provoquer toutes sortes de verrous qui vous empêchent.

Il n'y a pas de bonnes raisons de ne pas les utiliser ... à moins que les lignes orphelines ne soient pas un gros problème pour vous, je suppose.

La plus grande question est: voudriez-vous conduire avec les yeux bandés? C'est comme ça si vous développez un système sans contraintes référentielles. Gardez à l'esprit que les exigences métier changent, les modifications de conception d'application, les hypothèses logiques respectives dans les changements de code, la logique elle-même peut être refactorisée, etc. En général, les contraintes dans les bases de données sont mises en place sous des hypothèses logiques contemporaines, apparemment correctes pour un ensemble particulier d'assertions et d'hypothèses logiques.

Tout au long du cycle de vie d'une application, les contraintes de référentiel et de vérification des données contrôlent la collecte de données via l'application, en particulier lorsque de nouvelles exigences entraînent des changements d'application logiques.

Au sujet de cette liste - une clé étrangère n'améliore pas en soi les performances ni ne dégrade les performances de manière significative du point de vue du système de traitement des transactions en temps réel. Cependant, il existe un coût agrégé pour la vérification des contraintes dans le système "batch" à volume ÉLEVÉ. Voici donc la différence, en temps réel par rapport au processus de transaction par lots; traitement par lots - où le coût accru, encouru par les contrôles de contraintes, d'un lot traité séquentiellement pose un problème de performance.

Dans un système bien conçu, des contrôles de cohérence des données seraient effectués "avant" le traitement d'un lot (néanmoins, il y a un coût associé ici également); par conséquent, les vérifications des contraintes de clé étrangère ne sont pas requises pendant le temps de chargement. En fait, toutes les contraintes, y compris la clé étrangère, doivent être temporairement désactivées jusqu'à ce que le lot soit traité.

PERFORMANCE DE LA REQUÊTE - si les tables sont jointes sur des clés étrangères, sachez que les colonnes de clés étrangères NE SONT PAS INDEXÉES (bien que la clé primaire respective soit indexée par définition). En indexant une clé étrangère, d'ailleurs, en indexant n'importe quelle clé, et en joignant des tables sur des indexés aide à de meilleures performances, pas en se joignant à une clé non indexée avec une contrainte de clé étrangère.

Changement de sujet , si une base de données ne prend en charge que l'affichage / rendu du contenu / etc du site Web et l'enregistrement des clics, alors une base de données avec des contraintes complètes sur toutes les tables est trop efficace à ces fins. Pensez-y. La plupart des sites Web n'utilisent même pas de base de données pour cela. Pour des exigences similaires, lorsque les données sont simplement enregistrées et non référencées par exemple, utilisez une base de données en mémoire, qui n'a pas de contraintes. Cela ne signifie pas qu'il n'y a pas de modèle de données, oui un modèle logique, mais pas de modèle de données physique.

Raison supplémentaire d'utiliser des clés étrangères: - Permet une plus grande réutilisation d'une base de données

Raison supplémentaire de NE PAS utiliser de clés étrangères: - Vous essayez de verrouiller un client dans votre outil en réduisant la réutilisation.

D'après mon expérience, il est toujours préférable d'éviter d'utiliser des FK dans les applications critiques de base de données. Je ne serais pas en désaccord avec les gars ici qui disent que les FK sont une bonne pratique mais ce n'est pas pratique lorsque la base de données est énorme et a d'énormes opérations CRUD / sec. Je peux partager sans nommer ... l'une des plus grandes banques d'investissement n'a pas un seul FK dans les bases de données. Ces contraintes sont gérées par les programmeurs lors de la création d'applications impliquant DB. La raison fondamentale est que chaque fois qu'un nouveau CRUD est effectué, il doit effectuer plusieurs tables et vérifier pour chaque insertions / mises à jour, bien que ce ne soit pas un gros problème pour les requêtes affectant des lignes uniques, mais cela crée une latence énorme lorsque vous traitez avec traitement par lots que toute grande banque doit effectuer au quotidien.

Il vaut mieux éviter les FK, mais son risque doit être géré par les programmeurs.

"Avant d'ajouter un enregistrement, vérifiez qu'un enregistrement correspondant existe dans une autre table" est la logique métier.

Voici quelques raisons pour lesquelles vous ne voulez pas cela dans la base de données:

1. Si les règles métier changent, vous devez changer la base de données. La base de données devra recréer l'index dans de nombreux cas, ce qui est lent sur les grandes tables. (Les règles changeantes incluent: autoriser les invités à publier des messages ou autoriser les utilisateurs à supprimer leur compte malgré la publication de commentaires, etc.).

2. Changer la base de données n'est pas aussi simple que déployer un correctif logiciel en poussant les modifications vers le référentiel de production. Nous voulons éviter autant que possible de modifier la structure de la base de données. Plus la base de données contient de logique métier, plus vous augmentez les chances de devoir modifier la base de données (et déclencher une réindexation).

3. TDD. Dans les tests unitaires, vous pouvez remplacer la base de données par des simulations et tester la fonctionnalité. Si vous avez une logique métier dans votre base de données, vous ne faites pas de tests complets et vous devrez soit tester avec la base de données, soit répliquer la logique métier dans le code à des fins de test, dupliquer la logique et augmenter la probabilité que la logique ne fonctionne pas dans le de la même façon.

4. Réutiliser votre logique avec différentes sources de données. S'il n'y a pas de logique dans la base de données, mon application peut créer des objets à partir des enregistrements de la base de données, les créer à partir d'un service Web, d'un fichier json ou de toute autre source. J'ai juste besoin d'échanger l'implémentation du mappeur de données et je peux utiliser toute ma logique métier avec n'importe quelle source. S'il y a de la logique dans la base de données, cela n'est pas possible et vous devez implémenter la logique au niveau de la couche du mappeur de données ou dans la logique métier. Dans tous les cas, vous avez besoin de ces vérifications dans votre code. S'il n'y a pas de logique dans la base de données, je peux déployer l'application à différents emplacements en utilisant différentes implémentations de base de données ou de fichiers plats.

Je suis d'accord avec les réponses précédentes en ce qu'elles sont utiles pour maintenir la cohérence des données. Cependant, il y a quelques semaines, Jeff Atwood a publié un article intéressant sur les avantages et les inconvénients de données normalisées et cohérentes.

En quelques mots, une base de données dénormalisée peut être plus rapide lors du traitement de grandes quantités de données; et vous pouvez ne pas vous soucier de la cohérence précise en fonction de l'application, mais cela vous oblige à être beaucoup plus prudent lorsque vous traitez des données, comme la base de données ne le sera pas.

La base de données Clarify est un exemple de base de données commerciale sans clé primaire ou étrangère.

http://www.geekinterview.com/question_details/18869

Le plus drôle, c'est que la documentation technique va très loin pour expliquer comment les tables sont liées, quelles colonnes utiliser pour les joindre, etc.

En d'autres termes, ils auraient pu rejoindre les tables avec des déclarations explicites (DRI) mais ils ont choisi de ne pas le faire .

Par conséquent, la base de données Clarify est pleine d'incohérences et elle est sous-performante.

Mais je suppose que cela a facilité le travail des développeurs, sans avoir à écrire du code pour gérer l'intégrité référentielle, comme la vérification des lignes associées avant de supprimer, d'ajouter.

Et c'est, je pense, le principal avantage de ne pas avoir de contraintes de clé étrangère dans une base de données relationnelle. Cela facilite le développement, du moins c'est du point de vue du diable.

Je ne connais que les bases de données Oracle, pas d'autres, et je peux dire que les clés étrangères sont essentielles pour maintenir l'intégrité des données. Avant d'insérer des données, une structure de données doit être créée et corrigée. Lorsque cela est fait - et donc toutes les clés primaires ET étrangères sont créées - le travail est terminé!

Signification: lignes orphelines? Non. Je n'ai jamais vu ça de ma vie. Sauf si un mauvais programmeur a oublié la clé étrangère, ou s'il l'a implémentée à un autre niveau. Les deux sont - dans le contexte d'Oracle - d'énormes erreurs, qui entraîneront une duplication des données, des données orphelines et donc: une corruption des données. Je ne peux pas imaginer une base de données sans FK imposé. Cela ressemble à du chaos pour moi. C'est un peu comme le système d'autorisation Unix: imaginez que tout le monde est root. Pensez au chaos.

Les clés étrangères sont essentielles, tout comme les clés primaires. C'est comme dire: et si on supprimait les clés primaires? Eh bien, le chaos total va se produire. C'est ce que. Vous ne pouvez pas déplacer la responsabilité de clé primaire ou étrangère au niveau de programmation, elle doit être au niveau des données.

Désavantages ? Oui absolument ! Parce qu'à l'insertion, beaucoup plus de contrôles vont se produire. Mais, si l'intégrité des données est plus importante que les performances, c'est une évidence. Le problème avec les performances sur Oracle est plus lié aux index, qui viennent avec PK et FK.

Ils peuvent rendre la suppression des enregistrements plus lourde - vous ne pouvez pas supprimer l'enregistrement "maître" où il y a des enregistrements dans d'autres tables où les clés étrangères violeraient cette contrainte. Vous pouvez utiliser des déclencheurs pour effectuer des suppressions en cascade.

Si vous avez mal choisi votre clé primaire, la modification de cette valeur devient encore plus complexe. Par exemple, si j'ai le PK de ma table "clients" comme nom de la personne et que cette clé est un FK dans la table "commandes", si le client veut changer son nom, alors c'est une douleur royale .. . mais c'est juste une conception de base de données de mauvaise qualité.

Je pense que les avantages de l'utilisation des clés Fireign l'emportent sur tous les inconvénients supposés.

La vérification des contraintes de clé étrangère prend un certain temps CPU, donc certaines personnes omettent les clés étrangères pour obtenir des performances supplémentaires.

J'ai également entendu cet argument - de personnes qui ont oublié de mettre un index sur leurs clés étrangères et se sont ensuite plaintes que certaines opérations étaient lentes (car la vérification des contraintes pouvait profiter de n'importe quel index). Donc, pour résumer: il n'y a aucune bonne raison de ne pas utiliser de clés étrangères. Toutes les bases de données modernes prennent en charge les suppressions en cascade, donc ...

L'argument que j'ai entendu est que le front-end devrait avoir ces règles commerciales. Les clés étrangères "ajoutent une surcharge inutile" alors que vous ne devriez pas autoriser les insertions qui rompent vos contraintes en premier lieu. Suis-je d'accord avec cela? Non, mais c'est ce que j'ai toujours entendu.

EDIT: Je suppose qu'il faisait référence aux contraintes de clé étrangère , pas aux clés étrangères en tant que concept.

Pour moi, si vous voulez respecter les normes ACID , il est essentiel d'avoir des clés étrangères pour assurer l'intégrité référentielle.

Je dois appuyer la plupart des commentaires ici, les clés étrangères sont des éléments nécessaires pour garantir que vous avez des données avec intégrité. Les différentes options pour ON DELETE et ON UPDATE vous permettront de contourner certaines des «chutes» que les gens mentionnent ici concernant leur utilisation.

Je trouve que dans 99% de tous mes projets, je disposerai de FK pour faire respecter l'intégrité des données, cependant, il y a de rares occasions où j'ai des clients qui DOIVENT conserver leurs anciennes données, quelle que soit leur gravité ... mais ensuite je passe beaucoup de temps à écrire du code qui n'entre de toute façon que pour obtenir les données valides, donc cela devient inutile.

Qu'en est-il de la maintenabilité et de la constance à travers les cycles de vie des applications? La plupart des données ont une durée de vie plus longue que les applications qui les utilisent. Les relations et l'intégrité des données sont beaucoup trop importantes pour laisser espérer que la prochaine équipe de développement réussira dans le code de l'application. Si vous n'avez pas travaillé sur une base de données avec des données sales qui ne respectent pas les relations naturelles, vous le ferez. L'importance de l'intégrité des données deviendra alors très claire.

Je pense également que les clés étrangères sont une nécessité dans la plupart des bases de données. Le seul inconvénient (en plus du résultat de performance associé à la cohérence forcée) est que le fait d'avoir une clé étrangère permet aux gens d'écrire du code qui suppose qu'il existe une clé étrangère fonctionnelle. Cela ne devrait jamais être autorisé.

Par exemple, j'ai vu des gens écrire du code qui s'insère dans la table référencée, puis tente d'insérer dans la table de référence sans vérifier que la première insertion a réussi. Si la clé étrangère est supprimée ultérieurement, cela se traduit par une base de données incohérente.

Vous n'avez pas non plus la possibilité d'assumer un comportement spécifique lors de la mise à jour ou de la suppression. Vous devez toujours écrire votre code pour faire ce que vous voulez, qu'il y ait ou non une clé étrangère. Si vous supposez que les suppressions sont en cascade alors qu'elles ne le sont pas, vos suppressions échoueront. Si vous supposez que les mises à jour des colonnes référencées sont propagées aux lignes de référence lorsqu'elles ne le sont pas, vos mises à jour échoueront. Pour écrire du code, vous pourriez aussi bien ne pas avoir ces fonctionnalités.

Si ces fonctionnalités sont activées, votre code les émulera de toute façon et vous perdrez un peu de performances.

Donc, le résumé .... Les clés étrangères sont essentielles si vous avez besoin d'une base de données cohérente. Les clés étrangères ne doivent jamais être supposées être présentes ou fonctionnelles dans le code que vous écrivez.

Je fais écho à la réponse de Dmitriy - très bien mise.

Pour ceux qui s'inquiètent des surcharges de performances que les FK apportent souvent, il existe un moyen (dans Oracle) d'obtenir l'avantage d'optimiseur de requêtes de la contrainte FK sans les coûts de validation des contraintes lors de l'insertion, de la suppression ou de la mise à jour. Il s'agit de créer la contrainte FK avec les attributs RELY DISABLE NOVALIDATE. Cela signifie que l'optimiseur de requêtes suppose que la contrainte a été appliquée lors de la génération des requêtes, sans que la base de données applique réellement la contrainte. Vous devez être très prudent ici pour prendre la responsabilité lorsque vous remplissez une table avec une contrainte FK comme celle-ci pour vous assurer absolument que vous n'avez pas de données dans vos colonnes FK qui violent la contrainte, comme si vous le faites, vous pourrait obtenir des résultats peu fiables à partir de requêtes impliquant la table sur laquelle cette contrainte FK est activée.

J'utilise généralement cette stratégie sur certaines tables de mon schéma de magasin de données, mais pas dans mon schéma de transfert intégré. Je m'assure que les tables à partir desquelles je copie des données ont déjà la même contrainte appliquée, ou que la routine ETL applique la contrainte.

Beaucoup de personnes répondant ici sont trop accrochées à l'importance de l'intégrité référentielle implémentée via des contraintes référentielles. Travailler sur de grandes bases de données avec intégrité référentielle ne fonctionne tout simplement pas bien. Oracle semble particulièrement mauvais pour les suppressions en cascade. Ma règle générale est que les applications ne doivent jamais mettre à jour la base de données directement et doivent se faire via une procédure stockée. Cela conserve la base de code à l'intérieur de la base de données et signifie que la base de données conserve son intégrité.

Lorsque de nombreuses applications peuvent accéder à la base de données, des problèmes surviennent en raison de contraintes d'intégrité référentielle, mais cela est dû à un contrôle.

Il y a aussi un problème plus large en ce sens que les développeurs d'applications peuvent avoir des exigences très différentes que les développeurs de bases de données ne connaissent pas nécessairement.

Si vous êtes absolument sûr que le système de base de données sous-jacent ne changera pas à l'avenir, j'utiliserais des clés étrangères pour garantir l'intégrité des données.

Mais voici une autre très bonne raison concrète de ne pas utiliser du tout de clés étrangères:

Vous développez un produit qui devrait prendre en charge différents systèmes de base de données.

Si vous travaillez avec Entity Framework, qui est capable de se connecter à de nombreux systèmes de base de données différents, vous pouvez également prendre en charge les bases de données sans serveur "open-source-free-of-charge". Toutes ces bases de données peuvent ne pas prendre en charge vos règles de clé étrangère (mise à jour, suppression de lignes ...).

Cela peut entraîner différents problèmes:

1.) Vous pouvez rencontrer des erreurs lorsque la structure de la base de données est créée ou mise à jour. Peut-être qu'il n'y aura que des erreurs silencieuses, car vos clés étrangères sont simplement ignorées par le système de base de données.

2.) Si vous comptez sur des clés étrangères, vous effectuerez de manière appropriée, voire aucune vérification de l'intégrité des données dans votre logique métier. Maintenant, si le nouveau système de base de données ne prend pas en charge ces règles de clé étrangère ou se comporte simplement d'une manière différente, vous devez réécrire votre logique métier.

Vous pouvez vous demander: qui a besoin de différents systèmes de base de données? Eh bien, tout le monde ne peut pas se permettre ou veut un SQL-Server complet sur sa machine. Il s'agit d'un logiciel qui doit être maintenu. D'autres ont déjà investi du temps et de l'argent dans un autre système DB. La base de données sans serveur est idéale pour les petits clients sur une seule machine.

Personne ne sait comment se comportent tous ces systèmes de base de données, mais votre logique métier, avec les contrôles d'intégrité, reste toujours la même.

J'ai toujours pensé que c'était paresseux de ne pas les utiliser. On m'a appris que cela devrait toujours être fait. Mais ensuite, je n'ai pas écouté la discussion de Joel. Il avait peut-être une bonne raison, je ne sais pas.

Une fois qu'un FK peut vous poser un problème, c'est lorsque vous avez des données historiques qui font référence à la clé (dans une table de recherche) même si vous ne voulez plus que la clé soit disponible.
De toute évidence, la solution consiste à mieux concevoir les choses à l'avance, mais je pense à des situations réelles ici où vous n'avez pas toujours le contrôle de la solution complète.
Par exemple: vous avez peut-être une table de recherche customer_typequi répertorie différents types de clients - disons que vous devez supprimer un certain type de client, mais (en raison de contraintes commerciales) ne sont pas en mesure de mettre à jour le logiciel client, et personne n'a invisited cette situation lors du développement du logiciel, le fait qu'il s'agisse d'une clé étrangère dans une autre table peut vous empêcher de supprimer la ligne même si vous connaissez les données historiques qui y font référence, elles ne sont pas pertinentes.
Après avoir été brûlé avec cela plusieurs fois, vous vous éloignez probablement de l'application des relations avec les bases de données.
(Je ne dis pas que c'est bon - je donne juste une raison pour laquelle vous pouvez décider d'éviter les contraintes FK et db en général)