Les clés étrangères sont-elles vraiment nécessaires dans une conception de base de données?

Autant que je sache, les clés étrangères (FK) sont utilisées pour aider le programmeur à manipuler correctement les données. Supposons qu'un programmeur fasse déjà cela de la bonne manière, alors avons-nous vraiment besoin du concept de clés étrangères?

Existe-t-il d'autres utilisations des clés étrangères? Est-ce que j'ai râté quelque chose?

Les clés étrangères aident à renforcer l'intégrité référentielle au niveau des données. Ils améliorent également les performances car ils sont normalement indexés par défaut.

Les clés étrangères peuvent également aider le programmeur à écrire moins de code en utilisant des choses comme ON DELETE CASCADE. Cela signifie que si vous avez une table contenant des utilisateurs et une autre contenant des commandes ou quelque chose, la suppression d'un utilisateur pourrait supprimer automatiquement toutes les commandes qui pointent vers cet utilisateur.

Je ne peux pas imaginer concevoir une base de données sans clés étrangères. Sans eux, vous finirez par faire une erreur et corrompre l'intégrité de vos données.

Ils ne sont pas obligatoires à proprement parler, mais les avantages sont énormes.

Je suis assez certain que FogBugz n'a pas de contraintes de clé étrangère dans la base de données. Je serais intéressé d'apprendre comment l'équipe de Fog Creek Software structure son code pour garantir qu'elle n'introduira jamais d'incohérence.

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 consacrer ce peu de temps supplémentaire aux principes de base de la conception et à l'intégrité des données est un moyen infaillible de garantir des maux de tête plus tard.

Accepteriez-vous du code dans votre application qui était aussi bâclé? Cela accédait directement aux objets membres et modifiait directement les structures de données.

Pourquoi pensez-vous que cela a été rendu difficile et même inacceptable dans les langues modernes?

Oui.

1. Ils vous gardent honnête
2. Ils gardent les nouveaux développeurs honnêtes
3. Tu peux faire ON DELETE CASCADE
4. Ils vous aident à générer de jolis diagrammes qui expliquent eux-mêmes les liens entre les tables

Supposons qu'un programmeur fasse déjà cela de la bonne manière

Faire une telle supposition me paraît être une très mauvaise idée; en général, les logiciels sont extrêmement bogués.

Et c'est le point, vraiment. Les développeurs ne peuvent pas faire les choses correctement, donc s'assurer que la base de données ne peut pas être remplie de mauvaises données est une bonne chose.

Bien que dans un monde idéal, les jointures naturelles utiliseraient des relations (c'est-à-dire des contraintes FK) plutôt que des noms de colonnes correspondants. Cela rendrait les FK encore plus utiles.

Personnellement, je suis favorable aux clés étrangères car cela formalise la relation entre les tables. Je me rends compte que votre question présuppose que le programmeur n'introduit pas de données qui violeraient l'intégrité référentielle, mais j'ai vu beaucoup trop de cas où l'intégrité référentielle des données est violée, malgré les meilleures intentions!

Les contraintes de clé pré-étrangère (c'est-à-dire l'intégrité référentielle déclarative ou DRI) ont été consacrées à l'implémentation de ces relations à l'aide de déclencheurs. Le fait que l'on puisse formaliser la relation par une contrainte déclarative est très puissant.

@John - D'autres bases de données peuvent créer automatiquement des index pour les clés étrangères, mais pas SQL Server. Dans SQL Server, les relations de clé étrangère ne sont que des contraintes. Vous devez définir votre index sur les clés étrangères séparément (ce qui peut être avantageux).

Edit: Je voudrais ajouter que, IMO, l'utilisation de clés étrangères à l'appui de ON DELETE ou ON UPDATE CASCADE n'est pas nécessairement une bonne chose. En pratique, j'ai trouvé que la cascade lors de la suppression devrait être soigneusement considérée en fonction de la relation des données - par exemple, avez-vous un parent-enfant naturel où cela peut être OK ou la table associée est-elle un ensemble de valeurs de recherche. L'utilisation de mises à jour en cascade implique que vous autorisez la modification de la clé primaire d'une table. Dans ce cas, j'ai un désaccord philosophique général en ce que la clé primaire d'une table ne doit pas changer. Les clés doivent être intrinsèquement constantes.

Sans clé étrangère, comment savoir que deux enregistrements dans des tables différentes sont liés?

Je pense que vous faites référence à l'intégrité référentielle, où l'enregistrement enfant n'est pas autorisé à être créé sans enregistrement parent existant, etc. Celles-ci sont souvent appelées contraintes de clé étrangère - mais ne doivent pas être confondues avec l'existence de clés étrangères dans la première place.

Y a-t-il un avantage à ne pas avoir de clés étrangères? À moins que vous n'utilisiez une base de données de merde, les FK ne sont pas si difficiles à configurer. Alors, pourquoi auriez-vous une politique pour les éviter? C'est une chose d'avoir une convention de dénomination qui dit qu'une colonne en référence une autre, c'est une autre de savoir que la base de données vérifie réellement cette relation pour vous.

Je suppose que vous parlez de contraintes de clé étrangère imposées par la base de données . Vous utilisez probablement déjà des clés étrangères, vous n'en avez simplement pas informé la base de données.

Supposons qu'un programmeur fasse déjà cela de la bonne manière, alors avons-nous vraiment besoin du concept de clés étrangères?

Théoriquement, non. Cependant, il n'y a jamais eu de logiciel sans bogues.

Les bogues dans le code de l'application ne sont généralement pas si dangereux - vous identifiez le bogue et le corrigez, puis l'application s'exécute à nouveau correctement. Mais si un bogue permet aux données currupt d'entrer dans la base de données, alors vous êtes coincé! Il est très difficile de récupérer des données corrompues dans la base de données.

Considérez si un bogue subtil dans FogBugz a permis l' écriture d' une clé étrangère corrompue dans la base de données. Il peut être facile de corriger le bogue et de transmettre rapidement le correctif aux clients dans une version de correction de bogue. Cependant, comment corriger les données corrompues dans des dizaines de bases de données? Le code correct peut maintenant se rompre soudainement parce que les hypothèses sur l'intégrité des clés étrangères ne tiennent plus.

Dans les applications Web, vous n'avez généralement qu'un seul programme parlant à la base de données, il n'y a donc qu'un seul endroit où des bogues peuvent corrompre les données. Dans une application d'entreprise, il peut y avoir plusieurs applications indépendantes parlant à la même base de données (sans parler des personnes travaillant directement avec le shell de la base de données). Il n'y a aucun moyen d'être sûr que toutes les applications suivent les mêmes hypothèses sans bogues, toujours et pour toujours.

Si des contraintes sont encodées dans la base de données, le pire qui puisse arriver avec les bogues est que l'utilisateur voit un message d'erreur affreux concernant une contrainte SQL non satisfaite. Ceci est de loin préférable à l'introduction de données currupt dans la base de données de votre entreprise, où elles interrompront à leur tour toutes vos applications ou conduiront simplement à toutes sortes de sorties erronées ou trompeuses.

Oh, et les contraintes de clé étrangère améliorent également les performances car elles sont indexées par défaut. Je ne vois aucune raison de ne pas utiliser de contraintes de clé étrangère.

Les FK sont très importants et devraient toujours exister dans votre schéma, sauf si vous êtes eBay .

Je pense qu'une seule chose à un moment donné doit être responsable d'assurer des relations valables.

Par exemple, Ruby on Rails n'utilise pas de clés étrangères, mais il valide toutes les relations lui-même. Si vous n'accédez à votre base de données qu'à partir de cette application Ruby on Rails, c'est très bien.

Cependant, si vous avez d'autres clients qui écrivent dans la base de données, alors sans clés étrangères, ils doivent implémenter leur propre validation. Vous avez alors deux copies du code de validation qui sont très probablement différentes, ce que tout programmeur devrait être capable de dire est un péché cardinal.

À ce stade, les clés étrangères sont vraiment nécessaires, car elles vous permettent de déplacer à nouveau la responsabilité vers un seul point.

Les clés étrangères permettent à quelqu'un qui n'a jamais vu votre base de données auparavant de déterminer la relation entre les tables.

Tout va peut-être bien maintenant, mais pensez à ce qui se passera lorsque votre programmeur partira et que quelqu'un d'autre devra prendre le relais.

Les clés étrangères leur permettront de comprendre la structure de la base de données sans parcourir des milliers de lignes de code.

Pour autant que je sache, les clés étrangères sont utilisées pour aider le programmeur à manipuler correctement les données.

Les FK permettent au DBA de protéger l'intégrité des données contre les tâtonnements des utilisateurs lorsque le programmeur ne parvient pas à le faire, et parfois de se protéger contre les tâtonnements des programmeurs.

Supposons qu'un programmeur fasse déjà cela de la bonne manière, alors avons-nous vraiment besoin du concept de clés étrangères?

Les programmeurs sont mortels et faillibles. Les FK sont déclaratifs, ce qui les rend plus difficiles à bousiller.

Existe-t-il d'autres utilisations des clés étrangères? Est-ce que j'ai râté quelque chose?

Bien que ce ne soit pas la raison pour laquelle ils ont été créés, les FK fournissent des indications fiables et solides aux outils de création de diagrammes et aux générateurs de requêtes. Ceci est transmis aux utilisateurs finaux, qui ont désespérément besoin d'indices fiables et solides.

Ils ne sont pas strictement nécessaires, de la même manière que les ceintures de sécurité ne sont pas strictement nécessaires. Mais ils peuvent vraiment vous éviter de faire quelque chose de stupide qui gâche votre base de données.

C'est tellement plus agréable de déboguer une erreur de contrainte FK que de devoir reconstruire une suppression qui a cassé votre application.

Ils sont importants, car votre application n'est pas le seul moyen de manipuler les données dans la base de données. Votre application peut gérer l'intégrité référentielle aussi honnêtement qu'elle le souhaite, mais il suffit d'un bozo avec les privilèges appropriés pour émettre une commande d'insertion, de suppression ou de mise à jour au niveau de la base de données, et toute application de l'intégrité référentielle de votre application est contournée. Mettre des contraintes FK au niveau de la base de données signifie que, à moins que ce bozo choisisse de désactiver la contrainte FK avant d'émettre sa commande, la contrainte FK provoquera l'échec d'une mauvaise instruction d'insertion / mise à jour / suppression avec une violation d'intégrité référentielle.

J'y pense en termes de coût / bénéfice ... Dans MySQL , l'ajout d'une contrainte est une seule ligne supplémentaire de DDL . C'est juste une poignée de mots clés et quelques secondes de réflexion. C'est le seul "coût" à mon avis ...

Les outils aiment les clés étrangères. Les clés étrangères empêchent les mauvaises données (c'est-à-dire les lignes orphelines) qui peuvent ne pas affecter la logique ou la fonctionnalité métier et par conséquent passer inaperçues et s'accumuler. Cela empêche également les développeurs qui ne sont pas familiers avec le schéma d'implémenter des morceaux entiers de travail sans se rendre compte qu'il leur manque une relation. Peut-être que tout va bien dans le cadre de votre application actuelle, mais si vous avez manqué quelque chose et qu'un jour quelque chose d'inattendu est ajouté (pensez aux rapports sophistiqués), vous pourriez être dans un endroit où vous devez nettoyer manuellement les mauvaises données qui s'accumulent depuis la création. du schéma sans vérification forcée de la base de données.

Le peu de temps qu'il faut pour codifier ce qui est déjà dans votre tête lorsque vous mettez les choses ensemble pourrait vous épargner, à vous ou à quelqu'un d'autre, un tas de chagrins des mois ou des années plus tard.

La question:

Existe-t-il d'autres utilisations des clés étrangères? Est-ce que j'ai râté quelque chose?

C'est un peu chargé. Insérez des commentaires, des indentations ou des noms de variables à la place des "clés étrangères" ... Si vous comprenez déjà parfaitement la chose en question, cela ne vous sert à rien.

Réduction de l'entropie. Réduisez le risque que des scénarios chaotiques se produisent dans la base de données. Nous avons du mal car il considère toutes les possibilités, donc, à mon avis, la réduction de l'entropie est la clé du maintien de tout système.

Lorsque nous faisons une hypothèse par exemple: chaque commande a un client que l'hypothèse doit être renforcée par quelque chose . Dans les bases de données, ce "quelque chose" est des clés étrangères.

Je pense que cela vaut le compromis en termes de vitesse de développement. Bien sûr, vous pouvez coder plus rapidement avec eux et c'est probablement pourquoi certaines personnes ne les utilisent pas. Personnellement, j'ai tué un certain nombre d'heures avec NHibernate et une contrainte de clé étrangère qui se met en colère lorsque j'effectue une opération. CEPENDANT, je sais quel est le problème, donc c'est moins un problème. J'utilise des outils normaux et il existe des ressources pour m'aider à contourner ce problème, peut-être même des personnes pour m'aider!

L'alternative est de permettre à un bogue de s'infiltrer dans le système (et avec suffisamment de temps, ce sera le cas) où une clé étrangère n'est pas définie et vos données deviennent incohérentes. Ensuite, vous obtenez un rapport de bogue inhabituel, enquêter et "OH". La base de données est vissée. Maintenant, combien de temps cela prendra-t-il pour réparer?

Vous pouvez afficher les clés étrangères comme une contrainte qui,

• Aide à maintenir l'intégrité des données
• Montrer comment les données sont liées les unes aux autres (ce qui peut aider à appliquer la logique et les règles métier)
• S'il est utilisé correctement, peut aider à augmenter l'efficacité avec laquelle les données sont extraites des tables.

Nous n'utilisons actuellement pas de clés étrangères. Et pour la plupart, nous ne le regrettons pas.

Cela dit, nous allons probablement commencer à les utiliser beaucoup plus dans un avenir proche pour plusieurs raisons, toutes deux pour des raisons similaires:

1. Diagramme. Il est tellement plus facile de produire un diagramme d'une base de données si des relations de clé étrangère sont correctement utilisées.

2. Support d'outils. Il est beaucoup plus facile de créer des modèles de données à l'aide de Visual Studio 2008 qui peuvent être utilisés pour LINQ to SQL s'il existe des relations de clé étrangère appropriées.

Donc, je suppose que mon point est que nous avons constaté que si nous faisons beaucoup de travail manuel SQL (requête de construction, requête d'exécution, blahblahblah), les clés étrangères ne sont pas nécessairement essentielles. Une fois que vous commencez à utiliser les outils, ils deviennent beaucoup plus utiles.

La meilleure chose à propos des contraintes de clé étrangère (et des contraintes en général, en réalité) est que vous pouvez vous y fier lorsque vous écrivez vos requêtes. De nombreuses requêtes peuvent devenir beaucoup plus compliquées si vous ne pouvez pas vous fier au modèle de données "vrai".

Dans le code, nous obtiendrons généralement juste une exception lancée quelque part - mais en SQL , nous obtiendrons généralement les «mauvaises» réponses.

En théorie, SQL Server pourrait utiliser des contraintes dans le cadre d'un plan de requête - mais à l'exception des contraintes de vérification pour le partitionnement, je ne peux pas dire que j'aie jamais été témoin de cela.

Les clés étrangères n'avaient jamais été explicites (table (colonne) REFERENCES CLÉS ÉTRANGÈRES) déclarées dans les projets (applications métiers et sites de réseaux sociaux) sur lesquels j'ai travaillé.

Mais il y avait toujours une sorte de convention de dénomination des colonnes qui étaient des clés étrangères.

C'est comme avec la normalisation de base de données - vous devez savoir ce que vous faites et quelles en sont les conséquences (principalement les performances).

Je connais les avantages des clés étrangères (intégrité des données, index pour la colonne de clé étrangère, outils conscients du schéma de base de données), mais j'ai aussi peur d'utiliser des clés étrangères en règle générale.

De plus, divers moteurs de base de données pourraient servir des clés étrangères d'une manière différente, ce qui pourrait entraîner des bogues subtils lors de la migration.

La suppression de toutes les commandes et factures du client supprimé avec ON DELETE CASCADE est l'exemple parfait d'un schéma de base de données beau mais mal conçu.

Oui. ON DELETE [RESTRICT | CASCADE] empêche les développeurs de bloquer les données, en gardant les données propres. J'ai récemment rejoint une équipe de développeurs Rails qui ne se concentrait pas sur les contraintes de base de données telles que les clés étrangères.

Heureusement, j'ai trouvé ceux-ci: http://www.redhillonrails.org/foreign_key_associations.html - Les plug-ins RedHill sur Ruby on Rails génèrent des clés étrangères en utilisant la convention sur le style de configuration . Une migration avec product_id créera une clé étrangère vers l' id dans la table products .

Découvrez les autres excellents plug-ins de RedHill , y compris les migrations intégrées dans des transactions.

Si vous prévoyez de générer votre code d'accès aux données, c'est-à-dire Entity Framework ou tout autre ORM, vous perdez entièrement la possibilité de générer un modèle hiérarchique sans clés étrangères