Pour autant que je sache, les clés étrangères (FK) sont utilisées pour aider le programmeur à manipuler les données de manière correcte. Supposons qu'un programmeur le fasse déjà de la bonne manière, alors avons-nous vraiment besoin du concept de clés étrangères ?
Y a-t-il d'autres utilisations des clés étrangères ? Est-ce que quelque chose m'échappe ?
Si vous avez besoin d'un index, créez-en un, mais cela ne devrait pas être une raison principale pour les FK. (En fait, dans certaines circonstances (plus d'insertions que de sélections, par exemple), le maintien d'un FK peut être plus lent. )
C'est une mauvaise réponse. Les FKs peuvent généralement ajouter des frais supplémentaires sans améliorer les performances.
Dans SQL-Server, ils ne sont pas indexés par défaut sur l'arbitre ou le référent. sqlskills.com/blogs/kimberly/
Les clés étrangères peuvent également aider le programmeur à écrire moins de code en utilisant des éléments tels que ON DELETE CASCADE . Cela signifie que si vous avez une table contenant les utilisateurs et une autre contenant les commandes ou autre, la suppression d'un utilisateur pourrait automatiquement supprimer toutes les commandes qui pointent vers cet utilisateur.
Greg Hewgill Cela pourrait potentiellement conduire à de nombreux problèmes. Vous devriez être très prudent avec des pensées comme DELETE CASCADE, car dans de nombreux cas, vous voudriez garder les ordres créés par un utilisateur lors de la suppression de l'utilisateur.
Bien que cela doive probablement être traité dans la couche logique de l'entreprise. Décider de conserver ou non les enregistrements enfants liés n'est pas tout à fait la même chose que de s'assurer qu'aucune valeur ne viole les relations de clé étrangère.
L'autre problème est l'audit. Si l'audit n'est pas effectué au niveau de la base de données, les mises à jour ou les suppressions en cascade invalideront votre piste d'audit.
Je ne peux pas imaginer concevoir une base de données sans clés étrangères. Sans elles, vous risquez de faire une erreur et d'altérer l'intégrité de vos données.
Ils ne sont pas requis à proprement parler, mais les avantages sont énormes.
Je suis presque certain que FogBugz n'a pas de contraintes de clé étrangère dans la base de données. Je serais intéressé de savoir comment le Fog Creek Software L'équipe structure son code pour garantir qu'elle n'introduira jamais d'incohérence.
Joel : "Jusqu'à présent, nous n'avons jamais eu de problème." Jusqu'à présent, je n'ai jamais foncé dans un lampadaire. Mais je pense toujours que c'est une bonne idée de porter une ceinture de sécurité ;-)
Il se peut que vous n'ayez jamais VU le problème, mais il est peut-être là... La plupart des bases de données utilisent une convention comme id_xxx qui est exactement la même chose que ixXXX.
@Joel : Des conventions de nommage à la place de l'application des règles ? Autant se débarrasser de la typographie tant qu'on y est.
Un schéma de base de données sans contraintes FK, c'est comme conduire sans ceinture de sécurité.
Un jour, vous le regretterez. Ne pas passer un peu plus de temps sur les fondamentaux de la conception et l'intégrité des données est un moyen sûr de s'assurer des maux de tête plus tard.
Accepteriez-vous dans votre application un code aussi peu soigné ? Qui accède directement aux objets membres et modifie directement les structures de données.
Pourquoi pensez-vous que cela a été rendu difficile et même inacceptable au sein des langues vivantes ?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
3 votes
Ce sujet revient souvent par ici. Je blâme Joel Spolsky :-). Il y a beaucoup de bonnes réponses ici ; plutôt que de retaper la mienne, je vais simplement vous donner un lien : stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys
82 votes
"Supposons qu'un programmeur le fasse déjà de la bonne manière" - je ne peux même pas imaginer un tel scénario.
12 votes
La "clé étrangère" est une idée, pas une technologie. C'est une règle relationnelle. Votre question est en fait de savoir si vous devez essayer d'appliquer la règle dans votre code ou laisser la base de données vous aider. Lorsque la concurrence est impliquée, il est préférable de laisser le moteur de base de données appliquer la règle, car il est au courant de TOUT ce qui se passe dans la base de données, alors que votre code ne peut pas l'être.
0 votes
@Triynko, le concept de clés étrangères n'est pas une règle relationnelle.
0 votes
@Triynko - Pour développer ce qui a été dit, les clés étrangères ne sont pas une règle relationnelle, elles sont une relation règle
5 votes
@lubos & cdeszaq. En fait, c'EST une règle relationnelle... c'est un sous-ensemble de la règle 10 des "Twleve Commandments" de Codd... "Integrity Independence", qui dit essentiellement que l'intégrité relationnelle du SGBDR doit être maintenue indépendamment de toute application qui y accède, ce qui est exactement ce que j'expliquais d'une manière facile à comprendre. Cette règle est mise en œuvre, entre autres, par les contraintes de clé étrangère. Donc oui, l'idée d'une clé étrangère est "une" règle relationnelle.
0 votes
@Triynko, c'est à moi de décider si je veux avoir une intégrité référentielle entre deux relations ou non. Il n'est écrit nulle part que si j'ai des relations Clients et Factures, je dois également avoir et maintenir l'intégrité référentielle entre elles. Je pense que nous sommes tous deux d'accord pour dire que c'est une bonne idée d'appliquer l'intégrité référentielle le cas échéant, mais c'est juste une bonne idée, pas une exigence du modèle relationnel.
1 votes
@lubos : Pour clarifier, vous parlez de savoir si vous allez utiliser ou non une fonctionnalité particulière, mais je parle de savoir si la présence de cette fonctionnalité est nécessaire pour avoir un SGBDR complet et entièrement fonctionnel. Les contraintes référentielles, si et quand vous choisissez de les utiliser, sont quelque chose qui devrait être mis en œuvre dans le SGBDR (plutôt que dans l'application), donc c'est une fonctionnalité qui devrait être là, et dans ce sens, c'est une exigence du modèle relationnel si vous voulez développer un SGBDR complet.
0 votes
Une clé étrangère est comme une clé primaire distante. Lorsque vous avez deux tables liées, une clé étrangère relie les données d'une table séparée, qui seraient autrement incluses (de manière redondante) dans la table originale. Le modèle relationnel sert à éliminer la redondance en séparant les données dans des tables liées, les clés étrangères sont donc fondamentales pour le modèle relationnel. Selon moi, si une relation existe, elle DEVRAIT être appliquée. Si vous choisissez de ne pas appliquer une telle relation, alors votre base de données est nulle :), elle ne conserve pas un enregistrement complet des événements et peut paralyser votre application avec des valeurs nulles à terme.
0 votes
@Triynko, s'il vous plaît ne dites pas relation si vous voulez dire relation. c'est confus parce que dans le modèle relationnel, la relation est un ensemble de tuples qui partagent le même type, pas une relation. aussi quand vous parlez d'éliminer la redondance, vous ne parlez pas du modèle relationnel, vous parlez de la normalisation de la base de données ou 3NF. le modèle relationnel doit adhérer à un ensemble minimal de règles définies dans la 1NF. l'intégrité référentielle, les clés étrangères, l'élimination des redondances ne sont pas des règles de la 1NF, donc elles ne sont pas des règles permettant de répondre aux exigences du modèle relationnel. j'espère que cela a du sens maintenant.
0 votes
@lubos : Une relation et un rapport sont la même chose. Ce que vous devez comprendre, c'est qu'une relation contraint deux relations disjointes (tables) en une seule relation logique. En d'autres termes, une relation implique deux relations qui, lorsqu'elles sont contraintes correctement, sont logiquement équivalentes à une seule relation. Lorsque vous écrivez une requête JOIN, le résultat est une relation UNIQUE (table). Ce que vous sous-entendez, c'est que le "modèle relationnel" décrit un tableur de base, et je ne suis absolument pas d'accord.
0 votes
De Wikipedia "Modèle relationnel" : "Le modèle relationnel des données permet au concepteur de la base de données de créer une représentation cohérente et logique de l'information. La cohérence est obtenue en incluant contraintes déclarées dans la conception de la base de données, que l'on appelle généralement le schéma logique . La théorie comprend un processus de normalisation de la base de données par lequel un modèle ayant certaines propriétés souhaitables peut être sélectionné à partir d'un ensemble de des alternatives logiquement équivalentes ."
0 votes
...suite : "La cohérence d'une base de données relationnelle est assurée, non pas par des règles intégrées aux applications qui l'utilisent, mais plutôt par des contraintes, déclarées comme faisant partie du schéma logique et appliquées par le SGBD pour toutes les applications. En général, les contraintes sont exprimées à l'aide d'opérateurs de comparaison relationnels, dont un seul, "est un sous-ensemble de" (), est théoriquement suffisant. En pratique, on s'attend à ce que plusieurs raccourcis utiles soient disponibles, dont les plus importants sont les contraintes de clé candidate (en réalité, superclé) et de clé étrangère."
0 votes
Laissez-moi reformuler "Ce que vous sous-entendez est..." en ce qui suit (puisque l'édition semble être désactivée) : "Ce que vous sous-entendez est... que le 'modèle relationnel' n'englobe pas les idées traitant du maintien de l'intégrité de la relation lorsqu'elle se trouve être physiquement disjointe à des fins de normalisation, mais je pense qu'il englobe cela."
0 votes
Notez que les "règles" de Codd n'exigent pas que les contraintes d'intégrité référentielle soient prises en charge par un SGBDR. La règle 10 spécifie simplement que les contraintes d'intégrité doivent être appliquées de manière indépendante - elle ne dit pas quel type de contraintes elles doivent être. En tout cas, les "règles" ne sont pas et n'ont jamais été destinées à être une définition du modèle relationnel. Il est clair qu'une base de données peut être relationnelle sans avoir une seule contrainte d'intégrité et un SGBDR pourrait même ne pas supporter l'intégrité (c'est juste qu'il n'aurait probablement pas beaucoup de clients).