Clés étrangères sont vraiment nécessaires dans une conception de base de données?

voix
95

Pour autant que je sache, les clés étrangères (FK) sont utilisés pour aider le programmeur pour manipuler les données de manière correcte. Supposons un programmeur est en train de faire cela dans la bonne manière déjà, alors pouvons-nous vraiment besoin le concept de clés étrangères?

Y a-t-il d'autres utilisations pour les clés étrangères? Est-ce que j'ai râté quelque chose?

Créé 20/08/2008 à 21:18
source utilisateur
Dans d'autres langues...                            


23 réponses

voix
96

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

Créé 20/08/2008 à 21:19
source utilisateur

voix
56

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

Créé 20/08/2008 à 21:22
source utilisateur

voix
42

Je ne peux pas imaginer la conception d'une base de données sans clés étrangères. Sans eux, finalement, vous êtes tenu de faire une erreur et corrompre l'intégrité de vos données.

Ils ne sont pas nécessaires , au sens strict, mais les avantages sont énormes.

Je suis assez certain que FogBugz ne pas la clé étrangère dans la base de données. Je serais intéressé de savoir comment les Fog Creek Software structures d'équipe leur code pour garantir qu'ils ne seront jamais introduire une incohérence.

Créé 20/08/2008 à 21:24
source utilisateur

voix
38

Un schéma de base de données sans contraintes FK est comme la conduite sans ceinture de sécurité.

Un jour, vous allez le regretter. Ne pas dépenser que peu de temps sur l'intégrité des principes fondamentaux de conception et de données est un moyen sûr d'assurer des maux de tête plus tard.

Accepteriez-vous le code dans votre application qui était que bâclée? Cela directement accessible les objets membres et modifiés directement les structures de données.

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

Créé 20/08/2008 à 23:29
source utilisateur

voix
20

Oui.

  1. Ils vous garder 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 des diagrammes agréables que l'auto expliquer les liens entre les tables
Créé 20/08/2008 à 21:37
source utilisateur

voix
13

Personnellement, je suis en faveur des clés étrangères, car il formalise la relation entre les tables. Je me rends compte que votre question suppose que le programmeur n'introduit des données qui serait contraire à l'intégrité référentielle, mais je l'ai vu trop de cas où l'intégrité du référentiel de données est violée, malgré les meilleures intentions!

beaucoup les principales contraintes pré-étrangères (aka intégrité référentielle ou DRI) de temps a été consacré la mise en œuvre de ces relations en utilisant des déclencheurs. Le fait que nous pouvons formaliser la relation par une contrainte déclarative est très puissant.

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

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

Créé 20/08/2008 à 21:35
source utilisateur

voix
12

Supposons un programmeur est en train de faire cela dans la bonne manière déjà

Faire une telle supposition me semble être une très mauvaise idée; dans le logiciel général est bogué phénoménalement.

Et c'est le point, vraiment. Les développeurs ne peuvent pas faire les choses, assurant ainsi la base de données ne peut pas être rempli de mauvaises données est une bonne chose.

Bien que dans un monde idéal, les jointures naturelles utiliserait des relations (c.-à-FK contraintes) plutôt que de correspondre les noms de colonnes. Cela rendrait encore plus utile FKs.

Créé 20/08/2008 à 21:35
source utilisateur

voix
8

Je suppose que vous parlez de contraintes clés étrangères appliquées par la base de données . Vous avez probablement déjà utilisent des clés étrangères, vous avez tout simplement pas dit la base de données à ce sujet.

Supposons un programmeur est en train de faire cela dans la bonne manière déjà, alors pouvons-nous vraiment besoin le concept de clés étrangères?

En théorie, non. Cependant, il n'y a jamais eu un morceau de logiciel sans bugs.

Bugs dans le code d'application sont généralement pas dangereux - vous identifiez le bogue et le réparer, et après que l'application fonctionne bien à nouveau. Mais si un bug permet aux données currupt d'entrer dans la base de données, alors vous êtes coincé avec elle! 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 une clé étrangère corrompue à écrire dans la base de données. Il pourrait être facile de corriger le bug et pousser rapidement le correctif aux clients dans une version de maintenance. Cependant, comment si les données corrompues dans des dizaines de bases de données soient fixes? Correct code peut maintenant se briser soudainement parce que les hypothèses sur l'intégrité des clés étrangères DonT détiennent plus.

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

Si les contraintes sont codées dans la base de données, le pire qui peut arriver avec des bugs est que l'utilisateur affiche un message d'erreur laid sur certains SQL contrainte non satisfaite. Ceci est beaucoup prefereable de laisser des données currupt dans votre base de données de l' entreprise, où elle à son tour briser toutes vos applications ou tout simplement conduire à toutes sortes de production faux ou trompeurs.

Oh, et les clés étrangères améliore également les performances car ils sont indexés par défaut. Je ne peux pas penser à une raison quelconque ne pas utiliser les clés étrangères.

Créé 17/09/2008 à 14:24
source utilisateur

voix
8

Y at-il un avantage de ne pas avoir les clés étrangères? Sauf si vous utilisez une base de données merdique, ne sont pas FKs si difficile à mettre en place. Alors, pourquoi auriez-vous une politique de les éviter? Il est une chose d'avoir une convention de nommage qui dit une colonne référence à une autre, il est une autre de savoir la base de données vérifie en fait cette relation pour vous.

Créé 22/08/2008 à 16:40
source utilisateur

voix
8

Sans une clé étrangère comment voulez-vous dire que deux enregistrements dans différents tableaux sont liés?

Je pense que vous faites référence est l'intégrité référentielle, où l'enregistrement enfant ne peut pas être créé sans enregistrement parent existant, etc. Ceux-ci sont souvent connus comme les clés étrangères - mais ne doivent pas être confondus avec l'existence de clés étrangères la première place.

Créé 20/08/2008 à 21:24
source utilisateur

voix
7

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

Créé 19/04/2009 à 15:53
source utilisateur

voix
6

Je pense que quelque chose unique à un moment donné doit être chargé d'assurer des relations valides.

Par exemple, Ruby on Rails ne pas utiliser les clés étrangères, mais il valide toutes les relations lui - même. Si vous ne jamais accéder à votre base de données à partir de cette application Ruby on Rails, cela est bien beau.

Toutefois, si vous avez d'autres clients qui sont en train d'écrire à la base de données, sans clés étrangères dont ils ont besoin pour mettre en œuvre leur propre validation. Vous avez alors deux copies du code de validation qui sont les plus susceptibles différents, que tout programmeur devrait être en mesure de dire est un péché cardinal.

À ce moment-là, les clés étrangères sont vraiment nécessaire, car ils vous permettent de déplacer la responsabilité d'un seul point à nouveau.

Créé 20/08/2008 à 21:28
source utilisateur

voix
5

Pour autant que je sache, les clés étrangères sont utilisées pour aider le programmeur pour manipuler les données de manière correcte.

DBA permettent FKs de protéger l' intégrité des données du tâtonnement des utilisateurs lorsque le programmeur ne le faire, et parfois pour protéger contre le tâtonnement des programmeurs.

Supposons un programmeur est en train de faire cela dans la bonne manière déjà, alors pouvons-nous vraiment besoin le concept de clés étrangères?

Les programmeurs sont mortels et faillibles. Sont FKs déclarative qui les rend plus difficiles à bousiller.

Y a-t-il d'autres utilisations pour les clés étrangères? Est-ce que j'ai râté quelque chose?

Bien que ce n'est pas la raison pour laquelle ils ont été créés, faisant allusion fournissent FKs fort fiable aux outils et schématisation pour interroger les constructeurs. Ceci est transmis aux utilisateurs finaux, qui ont désespérément besoin de solides conseils fiables.

Créé 06/10/2008 à 22:26
source utilisateur

voix
5

Les clés étrangères permettent à une personne qui n'a pas vu votre base de données avant de déterminer la relation entre les tables.

Tout peut être bien maintenant, mais penser à ce qui se passera lorsque vos feuilles de programmeur et quelqu'un d'autre doit prendre le relais.

Les clés étrangères vont leur permettre de comprendre la structure de base de données sans la pêche au chalut par des milliers de lignes de code.

Créé 17/09/2008 à 05:44
source utilisateur

voix
4

Ils sont importants, parce que votre application n'est pas la seule façon dont les données peuvent être manipulées dans la base de données. Votre application peut gérer l'intégrité référentielle aussi honnêtement qu'il veut, mais tout ce qu'il faut est un bozo avec les privilèges droit de venir et d'émettre un insert, supprimer ou commande de mise à jour au niveau de la base de données, et toutes vos applications application de l'intégrité référentielle est contournée. Mettre les contraintes FK dans au niveau de base de données signifie que, sauf ce bozo choisir de désactiver la contrainte FK avant d'émettre leur commande, la contrainte FK entraînera une mauvaise insertion / mise à jour / supprimer déclaration à l'échec d'une violation de l'intégrité référentielle.

Créé 17/09/2008 à 20:09
source utilisateur

voix
4

Ils ne sont pas strictement nécessaire, dans la façon dont les ceintures de sécurité ne sont pas strictement nécessaires. Mais ils peuvent vraiment vous faire économiser de faire quelque chose de stupide qui salit votre base de données.

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

Créé 20/08/2008 à 21:57
source utilisateur

voix
3

Je pense en termes de coûts / avantages ... En MySQL , en ajoutant une contrainte est une ligne supplémentaire de LDD . Il est juste une poignée de mots clés et quelques secondes de la pensée. C'est le seul « coût » à mon avis ...

Outils aiment les clés étrangères. Les clés étrangères empêchent les mauvaises données (qui est, des lignes orphelins) qui ne peuvent pas affecter la logique métier ou de la fonctionnalité et à cet effet passer inaperçues, et de construire. Il empêche également les développeurs qui ne connaissent pas le schéma de mise en œuvre des pans entiers de travail sans se rendre compte qu'ils manquent une relation. Peut-être que tout est grand dans le cadre de l'application en cours, mais si vous avez manqué quelque chose et un jour quelque chose d'inattendu est ajouté (pensez à des rapports de fantaisie), vous pourriez être dans un endroit où vous devez nettoyer manuellement mauvaises données qui sont accumulées depuis la création du schéma sans une base de données vérification exécutée.

Le peu de temps qu'il faut pour codifier ce qui est déjà dans votre tête quand vous mettez des choses ensemble pourrait vous sauver ou quelqu'un d'autre un tas de mois de deuil ou des années sur la route.

La question:

Y a-t-il d'autres utilisations pour les clés étrangères? Est-ce que j'ai râté quelque chose?

Il est un peu chargé. Insérer des commentaires, indentation ou nom de la variable à la place des « clés étrangères » ... Si vous comprenez déjà la chose en question tout à fait, il est « inutile » pour vous.

Créé 21/08/2008 à 04:30
source utilisateur

voix
2

réduction entropique. Réduire le potentiel de scénarios chaotiques se produire dans la base de données. Nous avons un moment difficile car il envisage tous les possiblilites, à mon avis, la réduction d'entropie est essentielle pour le maintien de tout système.

Lorsque nous faisons une hypothèse par exemple: chaque commande a un client cette hypothèse devrait être appliquée par quelque chose . Dans les bases de données « quelque chose » est des clés étrangères.

Je pense que cela vaut le compromis entre la vitesse de développement. Bien sûr, vous pouvez coder plus rapidement avec eux hors et c'est probablement la raison pour laquelle certaines personnes ne les utilisent pas. Personnellement , je l' ai tué un certain nombre d'heures avec NHibernate et une contrainte de clé étrangère qui se met en colère quand j'exécute une opération. Cependant, je sais ce que le problème est il est donc moins un problème. J'utilise des outils normaux et il y a des ressources pour me aider à résoudre ce problème, peut - être même des gens pour aider!

L'alternative est de permettre à un bug de se glisser dans le système (et donné assez de temps, il) où une clé étrangère n'est pas définie et vos données devient incohérente. Ensuite, vous obtenez un rapport de bogue inhabituel, enquêter et « OH ». La base de données est vissé. Maintenant, combien de temps cela va-prendre pour corriger?

Créé 02/12/2009 à 00:22
source utilisateur

voix
1

Les clés étrangères avaient jamais été explicite (table RÉFÉRENCES FOREIGN KEY (colonne)) a déclaré dans les projets (applications et sites de réseautage social) que je travaillais sur.

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

Il est comme avec la normalisation de la base de données - vous devez savoir ce que vous faites et quelles sont conséquences de cette (principalement la performance).

Je suis conscient des avantages des clés étrangères (intégrité des données, index pour la colonne de clé étrangère, des outils au courant de schéma de base de données), mais je suis aussi peur d'utiliser les clés étrangères comme règle générale.

Aussi différents moteurs de base de données pourraient servir les clés étrangères d'une manière différente, ce qui pourrait conduire à des bugs subtils lors de la migration.

Suppression de toutes les commandes et les factures de client supprimé ON DELETE CASCADE est l'exemple parfait de Nice à la recherche, mais mal conçu, le schéma de base de données.

Créé 21/08/2008 à 10:06
source utilisateur

voix
1

La meilleure chose à propos des contraintes clés étrangères (et les contraintes en général, vraiment) sont que vous pouvez compter sur eux lors de l'écriture de vos requêtes. Un grand nombre de requêtes peut devenir beaucoup plus compliqué si vous ne pouvez pas compter sur le modèle de données contenant « true ».

Dans le code, nous allons généralement juste obtenir une exception levée quelque part - mais dans SQL , nous allons généralement juste obtenir les « mauvaises » réponses.

En théorie, SQL Server peut 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 je l' ai jamais fait que témoin.

Créé 20/08/2008 à 23:10
source utilisateur

voix
1

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

Cela dit - nous sommes susceptibles de commencer à les utiliser beaucoup plus dans un proche avenir pour plusieurs raisons, les deux pour des raisons similaires:

  1. Schématisation. Il est tellement plus facile de produire un diagramme d'une base de données s'il existe des relations clés étrangères correctement utilisées.

  2. Outils d'aide. Il est beaucoup plus facile de construire des modèles de données à l' aide de Visual Studio 2008 qui peut être utilisé pour LINQ to SQL s'il y a des relations propres clés étrangères.

Donc je suppose que mon point est que nous avons constaté que si nous faisons beaucoup de travail manuel SQL (construction de requête, exécutez la requête, blahblahblah) clés étrangères ne sont pas nécessairement indispensables. Une fois que vous commencez à entrer dans l'utilisation des outils, cependant, ils deviennent beaucoup plus utiles.

Créé 20/08/2008 à 21:55
source utilisateur

voix
1

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

  • Aide à maintenir l'intégrité des données
  • Montrer comment les données sont liées les unes aux autres (ce qui peut aider à faire respecter la logique métier et les règles)
  • Si elle est utilisée correctement, peut aider à augmenter l'efficacité avec laquelle les données sont extraites des tables.
Créé 20/08/2008 à 21:26
source utilisateur

voix
0

Oui. ON SUPPRIMER [RESTRICT | CASCADE] conserve les développeurs à partir des données d'échouage, en gardant les données propres. J'ai récemment rejoint une équipe de développeurs Rails qui ne se concentrent pas sur les contraintes de base de données telles que les clés étrangères.

Heureusement, je trouve ces: http://www.redhillonrails.org/foreign_key_associations.html - RedHill sur Ruby on Rails plug-ins génèrent des clés étrangères en utilisant la convention sur la configuration de style. Une migration avec product_id va créer une clé étrangère à l' id du produit table.

Consultez les autres grands plug-ins à RedHill , y compris les migrations enveloppées dans les transactions.

Créé 17/09/2008 à 05:30
source utilisateur

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more