web-dev-qa-db-fra.com

Pourquoi dois-je utiliser une clé étrangère si je peux utiliser WHERE?

Une question de débutant sur la clé étrangère dans MySQL.

Dans w3school il dit,

Une clé étrangère dans une table pointe vers une clé primaire dans une autre table.

Et aussi il y a O,

WHERE id = page_id

Donc, si je peux utiliser WHERE pour relier les tables, quel est le but principal de la clé étrangère?

mysqlforeign-keys
35
shin

Ce n'est pas strictement nécessaire pour la requête, c'est vrai. Il existe pour plusieurs raisons:

  1. Comme une contrainte sur la table pour vous empêcher d'insérer quelque chose qui ne pointe pas vers rien;
  2. Comme indice pour l'optimiseur; et
  3. Pour des raisons historiques, il était plus nécessaire de choisir.

(1) est probablement l'important des trois. Cela s'appelle intégrité référentielle . Cela signifie que s'il y a une valeur dans une clé étrangère, il y aura un enregistrement correspondant avec cette valeur comme clé primaire dans la table parente.

Cela étant dit, toutes les bases de données ne prennent pas en charge l'intégrité référentielle (par exemple, les tables MySQL/MyISAM) et celles qui ne l'appliquent pas nécessairement (pour des raisons de performances).

38
cletus

L'étranger est utilisé pour l'intégrité référentielle.

Voir Une introduction aux clés étrangères et à l'intégrité référentielle dans MySQL

7
Adriaan Stander

Donc, si je peux utiliser WHERE pour relier les tables, quel est le but principal de la clé étrangère?

Parce que la clause WHERE n'est pas limitée aux équijoins sur des clés étrangères.

Disons que si vous avez un tableau décrivant les fourchettes de prix et les remises, vous utilisez cette condition complexe pour joindre les tableaux:

SELECT  *
FROM    Goods
JOIN    PriceRange
ON      PriceRange.Price =
        (
        SELECT  MAX(Price)
        FROM    PriceRange
        WHERE   PriceRange.Price <= Goods.Price
        )

Vous ne pouvez pas lier ces tables avec une relation de clé étrangère, mais vous pouvez facilement les joindre.

Voir cette entrée dans mon blog pour plus de détails:

La liaison pk-à-pk, cependant, est toujours importante. Un FOREIGN KEY peut vous assurer que les entités auxquelles vous associez sont décrites par votre modèle relationnel.

Avec une conception soutenue par FOREIGN KEY-, vous ne pouvez pas déclarer une relation à une entité dont PRIMARY KEY est absent dans la table qui décrit cette entité.

SQL Server peut même prendre ce fait en compte et optimiser certains types de requêtes.

Dis, cette requête:

SELECT  f.*
FROM    t_foreign f
WHERE   f.pid IN
        (
        SELECT  id
        FROM    t_primary p
        )

ne cherchera même pas dans t_primary si la relation FOREIGN KEY est définie entre t_foreign et t_primary.

Voir cet article pour plus de détails:

5
Quassnoi

Maintien intégrité référentielle et indexation.

2
Garry Shutler

J'ai une autre bonne raison d'ajouter les relations de clé à votre base de données. Divers générateurs de code utilisent ces informations pour générer un modèle objet à partir de votre base de données. Un modèle notable couramment utilisé est le modèle ActiveRecord. Sans relations de clé, le modèle ActiveRecord ne saurait pas comment les entités de la base de données sont liées, ce qui générerait un modèle objet beaucoup moins utile.

La génération de code ne convient pas à tous les projets logiciels. Mais, cela est utile sur un grand nombre de projets. Si vous n'utilisez pas la génération de code, vous vous devez au moins de l'examiner.

1
Mark Ewer

L'objectif principal d'une clause WHERE est de limiter les lignes renvoyées par la requête. Voir SELECT Syntax .

Les relations clé primaire/clé étrangère maintiennent l'intégrité référentielle et, avec une indexation appropriée, améliorent les performances des requêtes. (Voir l'explication de Pete OHanlon ci-dessus et Types JOIN )

1
Jim H.

l'opérateur RESTRICT (WHERE) n'a rien à voir avec des contraintes référentielles!

citation de C. J. Date's Dictionnaire de base de données relationnelle

clé étrangère Soit R1 et R2voitures, non nécessairement distinctes, et soit K_ soit une clé pour R1. Soit FK un sous-ensemble de l'en-tête de R2 de telle sorte qu'il existe une séquence éventuellement vide de renommage d'attributs mappant K en K ' (par exemple), où K' et FK contiennent exactement les mêmes attributs. Alors FK est une clé étrangère

intégrité référentielle En gros, la règle selon laquelle aucun tuple de référence n'est autorisé à exister si le tuple référencé correspondant n'existe pas. Plus précisément, supposons que FK soit une clé étrangère dans une référence relvar R2; soit K _ soit la clé correspondante dans la relvar correspondante référencée R1, et soit K '_ soit dérivé de K comme décrit sous clé étrangère . Ensuite, la règle d'intégrité référentielle requiert qu'il n'y ait jamais d'heure à laquelle il existe une valeur FK dans R2 qui n'est pas la valeur K ' de certains (nécessairement uniques) Tuple dans R1 à l'époque en question. R1 et R2 ici sont respectivement la variable référence et la variable référence, et la contrainte qui les sépare est une contrainte référentielle.

Exemples: Dans relvar SP, {S#} et {P#} sont des clés étrangères correspondant aux clés {S#} et {P#} dans les relvars S et P, respectivement. Notez que la clé dans la variable de référence référencée qui correspond à une clé étrangère donnée ne doit pas nécessairement être une clé primaire.

1
just somebody

La contrainte FOREIGN KEY est utilisée pour empêcher les actions susceptibles de détruire les liens entre les tables.

La contrainte FOREIGN KEY empêche également l'insertion de données non valides dans la colonne de clé étrangère, car il doit s'agir d'une des valeurs contenues dans la table vers laquelle elle pointe.

0
shanthan

Une clé étrangère est utilisée pour maintenir l'intégrité référentielle, tandis qu'une clause WHERE est utilisée pour joindre des tables dans une opération SQL telle qu'une sélection. La clause where peut fonctionner sur plusieurs tables, mais elle est purement là en tant que filtre.

À proprement parler, vous pouvez vous en sortir sans intégrité référentielle, mais ce n'est pas une bonne idée. Sans intégrité référentielle, vous finissez par vous attendre à ce que votre application cliente ne supprime pas ou ne mette pas à jour, à une extrémité de la chaîne, quelque chose qui aurait des répercussions sur les données, par exemple. changer une valeur clé pour pointer vers une valeur absente.

L'intégrité référentielle est un excellent moyen de s'assurer que les données associées sont conservées de manière cohérente.

0
Pete OHanlon