Pourquoi les correspondances clé primaire / clé étrangère ne sont-elles pas utilisées pour les jointures?


48

Autant que je sache, de nombreux SGBD (par exemple, mysql, postgres, mssql) utilisent des combinaisons fk et pk uniquement pour limiter les modifications de données, mais ils sont rarement utilisés de manière native pour sélectionner automatiquement les colonnes à joindre (comme le fait la jointure naturelle avec des noms). Pourquoi donc? Si vous avez déjà défini une relation entre 2 tables avec un pk / fk, pourquoi la base de données ne peut-elle pas comprendre que si je joins ces tables, je veux les joindre sur les colonnes pk / fk?

EDIT: pour clarifier un peu:

supposons que j'ai une table1 et une table2. table1 on a une clé étrangère sur la colonne a, qui fait référence à la clé primaire sur table2, la colonne b. Maintenant, si je rejoins ces tables, je devrai faire quelque chose comme ceci:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

Cependant, j'ai déjà défini avec mes clés que table1.a fait référence à table2.b, il me semble donc qu'il ne devrait pas être trop difficile de faire en sorte qu'un système de SGBD utilise automatiquement table1.a et table2.b comme colonnes de jointure, de telle sorte que l'on peut simplement utiliser:

SELECT * FROM table1
AUTO JOIN table2

Cependant, beaucoup de SGBD ne semblent pas implémenter quelque chose comme ça.

Réponses:


32

Dans de nombreux cas, il existe plus d’une façon de joindre deux tables; Voir les autres réponses pour de nombreux exemples. Bien sûr, on pourrait dire que ce serait une erreur d’utiliser la «jointure automatique» dans ces cas. Il ne reste alors qu’une poignée de cas simples dans lesquels il peut être utilisé.

Cependant, il y a un grave inconvénient! Les requêtes qui sont correctes aujourd'hui pourraient devenir une erreur demain simplement en ajoutant un deuxième FK à la même table!

Permettez-moi de le répéter: en ajoutant des colonnes, les requêtes qui n'utilisent pas ces colonnes risquent de passer de "correct" à "erreur"!

C’est un tel cauchemar de maintenance que tout guide de style sensé interdirait l’utilisation de cette fonctionnalité. La plupart interdisent déjà select *pour la même raison!

Tout cela serait acceptable si les performances étaient améliorées. Cependant, ce n'est pas le cas.

En résumé, cette fonctionnalité pourrait n'être utilisée que dans un nombre limité de cas simples, n'augmente pas les performances, et la plupart des guides de style interdiraient de toute façon son utilisation.

Il n’est donc pas étonnant que la plupart des fournisseurs de bases de données choisissent de consacrer leur temps à des tâches plus importantes.


1
Il est probable qu’en réalité, les performances seront minimes, car il faut déterminer les colonnes de jointure plutôt que de les redéfinir.
HLGEM

1
@HLGEM, cela peut être mis en cache et ne pas être pertinent pour les requêtes plus volumineuses. L'avantage est que nous pouvons être sûrs que les clés ne sont pas oubliées à cause d'une erreur humaine.
Pacerier

L'ajout et la modification de colonnes peuvent également se briser NATURAL JOIN(c'est pourquoi je les évite généralement), mais je ne pense pas que cela devrait en soi signifier qu'un dbms ne pourrait pas implémenter un moyen automatique de joindre des tables basées sur des clés étrangères.
Jay K

2
Beaucoup de cas? Sur un millier de tables DB, je n'ai que quelques cas de relation plus-que-1 entre deux tables. Quoi qu'il en soit, ce n'est pas un problème, il suffirait d'ajouter le nom de la relation comme AUTO JOIN mytable THROUGH myrelation, ce serait très agréable.
Teejay

C'est ce que nous faisons dans notre générateur .NET SQL sur mesure, avec intellisense, commeInnerJoin(SRC_TABLE.rDEST_TABLE.REL_NAME_F01)
Teejay

27

Une clé étrangère est censée contraindre les données. c'est-à-dire appliquer l'intégrité référentielle. C'est ça. Rien d'autre.

  1. Vous pouvez avoir plusieurs clés étrangères dans la même table. Considérez ce qui suit lorsqu'un envoi a un point de départ et un point d'arrivée.

    table: USA_States
    StateID
    StateName
    
    table: Shipment
    ShipmentID
    PickupStateID Foreign key
    DeliveryStateID Foreign key

    Vous voudrez peut-être rejoindre en fonction de l'état de collecte. Peut-être que vous souhaitez rejoindre sur l'état de livraison. Peut-être que vous voulez effectuer 2 jointures pour les deux! Le moteur SQL n'a aucun moyen de savoir ce que vous voulez.

  2. Vous croiserez souvent des valeurs scalaires de jointure. Bien que les scalaires soient généralement le résultat de calculs intermédiaires, vous aurez parfois une table à usage spécifique avec exactement 1 enregistrement. Si le moteur essayait de détecter une clé étrangère pour la jointure ... cela n'aurait aucun sens, car les jointures croisées ne correspondent jamais à une colonne.

  3. Dans certains cas particuliers, vous rejoindrez des colonnes où ni l'une ni l'autre n'est unique. Par conséquent, la présence d'un PK / FK sur ces colonnes est impossible.

  4. Vous pouvez penser que les points 2 et 3 ci - dessus ne sont pas pertinents car vos questions est quand il EST un PK / FK relation entre les tables. Toutefois, la présence d'un seul fichier PK / FK entre les tables ne signifie pas que vous ne pouvez pas avoir d'autres champs à joindre en plus du fichier PK / FK. Le moteur SQL ne saurait pas quels champs vous souhaitez rejoindre.

  5. Disons que vous avez une table "USA_States" et 5 autres tables avec un FK aux états. Les "cinq" tables ont également quelques clés étrangères les unes aux autres. Le moteur SQL doit-il automatiquement rejoindre les "cinq" tables avec "USA_States"? Ou devrait-il joindre les "cinq" les uns aux autres? Tous les deux? Vous pouvez configurer les relations de sorte que le moteur SQL entre dans une boucle infinie en essayant de réunir des éléments. Dans cette situation, il est impossible au moteur SQL de deviner ce que vous voulez.

En résumé: PK / FK n'a rien à voir avec les jointures de table. Ce sont des choses distinctes sans rapport. C'est simplement un accident de la nature auquel vous vous associez souvent sur les colonnes PK / FK.

Souhaitez-vous que le moteur SQL devine s'il s'agit d'une jointure complète, gauche, droite ou interne? Je ne pense pas. Bien que ce serait sans doute un péché moindre que de deviner les colonnes à joindre.


7
Je considère que les clés étrangères et la normalisation sont très pertinentes pour les jointures de table.

3
Vos arguments sont valables lorsque le mot clé JOIN normal tente toujours de correspondre à cela (comme je me suis trompé dans mon exemple, je résous ce problème). Cependant, beaucoup de jointures peuvent être dérivées directement des seules jointures, donc je ne vois aucune raison pour laquelle il ne pourrait pas y avoir de syntaxe explicite pour les joindre. De nombreux SGBD ont une jointure naturelle, ce qui revient à la même chose mais avec des noms de colonne (= mauvais). La même chose pourrait être faite avec ce type de jointure, par exemple en spécifiant une opération AUTO JOIN.

5
"Ce n'est qu'un accident de la nature auquel vous vous associez souvent dans les colonnes PK / FK" - je ne suis pas convaincu!
quand

2
"Normalisation?" Je pense que la pensée ici est que si vous commencez avec une version 1NF, puis décomposée en versions 6NF, alors il y a de fortes chances que a) ils aient des clés étrangères lors de la mise en œuvre et b) qu'ils soient fréquemment joints à des requêtes.
onedaywhen

4
Je voterais s'il n'y avait pas que "PK / FK n'a rien à voir avec les jointures de table".
Ypercubeᵀᴹ

11

le concept de "joignabilité". Les relations r1et r2peuvent être jointes si et seulement si des attributs portant le même nom sont du même type ... Ce concept s'applique non seulement à la jointure en tant que telle, mais également à diverses autres opérations [telles que l'union].

Théorie SQL et relationnelle: comment écrire du code SQL précis par date CJ

Le SQL standard possède déjà une telle fonctionnalité, connue sous le nom de NATURAL JOIN, et a été implémentée dans mySQL.

Bien que votre suggestion ne soit pas aussi valable, elle semble raisonnable. Avec SQL Server (qui manque de prise en chargeNATURAL JOIN ), j’utilise SQL Prompt dans Management Studio: lorsqu’il écrit, INNER JOINInteliSense suggère des ONclauses basées à la fois sur les noms d’attributs courants et sur les clés étrangères et j’ai trouvé cela très utile. Je n'ai toutefois pas très envie de voir un nouveau type de jointure SQL (standard) pour cela.


1
La jointure naturelle et la jointure sur des colonnes communes est distincte et orthogonale de la notion de jointure sur FK-PK. (Voir ma réponse.)
philipxy

@philipxy: d'accord, je n'avais pas l'intention d'impliquer autrement. (Votre réponse est excellente!)
jour où le

9

SQL est arrivé en premier!

Les clés étrangères et les clés étrangères sont venues plus tard et sont essentiellement une optimisation pour les applications de type "transaction".

Les bases de données relationnelles ont été conçues à l'origine comme une méthode permettant d'appliquer des requêtes complexes à des ensembles de données de manière mathématiquement prouvable à l' aide de l'algèbre relationnelle. IE pour un ensemble de données donné et une requête donnée, il y a toujours une seule réponse correcte.

Les bases de données relationnelles ont parcouru un long chemin depuis lors, et leur utilisation principale comme couche de persistance pour les systèmes transactionnels n’était pas ce que CODD et. tout prévu.

Cependant, l'organisme de normalisation ANSI pour tous ses objectifs contradictoires et sa politique de fournisseurs s'est toujours efforcé de préserver les propriétés "prouvables du point de vue mathématique" de SQL.

Si vous autorisiez la base de données à déduire les propriétés de jointure à partir de données de clé étrangère "cachées", vous perdriez cette propriété (tenez compte de l'ambiguïté si plusieurs jeux de clés étrangères sont définis).

De plus, un programmeur qui lit le code SQL ne sait pas nécessairement quelles clés étrangères sont actuellement définies pour les deux tables et doit examiner le schéma de la base de données pour déterminer le résultat de la requête.


3
Merci, cela a eu un sens pour moi! Cependant, les jointures naturelles n'ont-elles pas les mêmes problèmes? Bien que les jointures naturelles aient même des problèmes plus importants, de nombreux SGBD les prennent en charge. OMI une jointure basée sur pk / fk serait une jointure naturelle bien faite.

1
Il n'y a pas de différence en ce qui concerne la plupart des moteurs de base de données entre une jointure naturelle et un "JOIN ... ON" explicite. Le moteur analyse la requête et effectue la jointure du mieux possible en fonction des différents prédicats. L'utilisation d'une jointure explicite ne force pas l'utilisation d'un index ou d'un chemin d'accès particulier, elle sert principalement à prendre en charge la syntaxe de jointure "LEFT, OUTER, INNER" qui doit connaître les prédicats de la jointure explicite pour savoir quand insérer une ligne "manquante" .

6
SQL n'est pas venu en premier! Le modèle relationnel (qui comprenait bien sûr le concept de clé étrangère) a été défini pour la première fois par EFCodd en 1969. SEQUEL, alors qu’il était alors, n’a pas vu le jour jusqu’en 1974. Ses inventeurs ont clairement indiqué dès le départ que SEQUEL / SQL devait être basé sur le modèle relationnel préexistant - bien que SQL ne soit pas vraiment un langage relationnel.
Nvogel

@sqlvogel - vrai! Aurait dû le dire "SQL a été implémenté en premier".
James Anderson

CJ Date dans 'Une introduction aux systèmes de bases de données' (p276) dit que Codd a inventé le concept de clé étrangère; ne dit pas quand mais je suppose que c'était avant la première implémentation SQL.
quand

7

Bien que vous ayez défini une relation de clé étrangère, cela ne signifie pas que vous souhaitiez joindre les tables dans toutes les requêtes. C'est la méthode la plus probable pour joindre les tables, mais il y a des cas où ce n'est pas correct.

  • Vous voudrez peut-être utiliser un produit cartésien des deux tables ou une partie de celle-ci à certaines fins.
  • Il peut y avoir d’autres domaines sur lesquels vous pouvez vous joindre dans un autre but.
  • Si vous joignez trois ou plusieurs tables, l'une d'entre elles peut être liée à deux ou plusieurs des tables. Dans ce cas, généralement, une seule des relations FK possibles peut être appropriée dans la requête.

7

Vous pouvez opérer sur une fausse hypothèse. Vous dites «aussi loin que vous pouvez le savoir» mais ne donnez aucune preuve empirique ou probante. Si pk ou fk sont le meilleur index pour une requête, il sera utilisé. Je ne sais pas pourquoi vous voyez cela, mais je suppose que les requêtes sont mal formées.


Éditez maintenant que la question a été totalement réécrite: le cas que vous décrivez ne serait que pour un très petit ensemble de requêtes. Que faire s'il y a 12 tables jointes? Et s'il n'y avait pas de FK ... Même s'il y avait une jointure par défaut, je spécifierais toujours la jointure uniquement pour des raisons de lisibilité. (Je ne veux pas avoir à regarder les données et ensuite essayer de comprendre ce qui est joint sur)

Certains outils de requête effectuent une jointure automatique pour vous, puis vous permettent de supprimer ou de modifier la jointure. Je pense que Query Builder de MS Access fait cela.

Enfin, la norme ANSII stipule que la jointure doit être spécifiée. C'est une raison suffisante pour ne pas le permettre.


3
Désolé, je n'ai peut-être pas été assez clair. Je ne parle pas d'index, je parle de jointures. Supposons que j'ai table1 et table2, avec un fk sur table1.a qui pointe sur table2.b. Si je joins ces tables, je devrai explicitement dire que je veux les joindre sur les colonnes a et b (par exemple, 'SELECT * FROM table1 JOIN table2 ON table1.a = table2.b '), alors que j'avais déjà défini dans ma base de données régime que ces deux sont liés. La question est pourquoi je ne peux pas faire 'SELECT * FROM table1 JOIN table2' et laisser le SGBD choisir automatiquement les colonnes de jointure en fonction du fk / pk.

4
Surtout la lisibilité a du sens pour moi! Cependant, le fait que la norme le spécifie n’est pas un très bon argument, OMI. De nombreuses normes ont déjà fait de mauvais choix (HTML par exemple).

3

La base de données ne peut pas le faire en toute sécurité pour de nombreuses raisons , notamment le fait que l'ajout / la suppression de clés étrangères modifie la signification des requêtes pré-écrites, y compris des requêtes dans le code source de l'application. La plupart des bases de données ne possèdent pas non plus un bon jeu de clés étrangères qui couvrent toutes les jointures possibles. Aussi, pour le meilleur ou pour le mieux, les clés étrangères sont souvent supprimées pour accélérer les systèmes et ne peuvent pas être utilisées sur des tables chargées dans le "mauvais" ordre à partir d'un fichier.

Cependant, il n'y a aucune raison pour laquelle un outil de conception de requête ou l'éditeur de texte ne puisse pas terminer automatiquement une jointure à l'aide de clés étrangères de la même manière qu'ils vous donnent l' intellisense sur le nom de colonne. Vous pouvez modifier la requête si l’outil s’est trompé et enregistrer une requête complètement définie. Un tel outil pourrait également utilement utiliser la convention consistant à nommer les colonnes de clés étrangères par le nom de table «parent» et les colonnes de même nom dans la table parent / enfant, etc.

(Ma femme ne comprend toujours pas la différence entre Management Studio et Sql Server et parle de démarrer serveur SQL quand elle démarre studio de gestion!)


3

La jointure naturelle "automatiquement" se joint à l'égalité des colonnes communes, mais vous ne devriez l'écrire que si vous le souhaitez, en vous basant sur les significations des tableaux et le résultat souhaité. Il n'y a pas "automatiquement" de savoir comment deux tables "devraient être jointes ou de toute autre manière que n'importe quelle table" devrait "apparaître dans une requête. Nous n'avons pas besoin de connaître les contraintes à interroger. Leur présence signifie simplement que les entrées peuvent être limitées et, par conséquent, la sortie peut l'être aussi. Vous pouvez définir un type d'opérateur join_on_fk_to_pk qui se joint "automatiquement" aux contraintes déclarées. mais si vous souhaitez que la signification de la requête reste la même si seules les contraintes changent mais pas les significations de table, vous devez modifier cette requête pour ne pas utiliser les nouvelles constaints déclarées.laisse déjà le même sens malgré tout changement de contrainte .

Les contraintes (telles que PK, FK, UNIQUE & CHECK) n’affectent pas la signification des tableaux. Bien sûr, si les significations de la table changent, les contraintes pourraient changer. Mais si les contraintes changent, cela ne signifie pas que les requêtes doivent changer.

Il n’est pas nécessaire de connaître les contraintes à interroger. Connaître les contraintes signifie que nous pouvons utiliser d'autres expressions qui, sans la contrainte, ne renverraient pas la même réponse. Par exemple, nous nous attendons via UNIQUE à ce qu'une table ait une ligne, nous pouvons donc l’utiliser comme scalaire. Ces requêtes peuvent être interrompues si la contrainte était supposée mais non déclarée. Mais déclarer une contrainte que la requête n'a pas assumée ne peut pas la rompre.

Existe-t-il une règle empirique pour construire une requête SQL à partir d'une description lisible par l'homme?


2

La raison en est qu'il y a le LANGAGE, puis les principes sous-jacents. Le langage est rare et manque de nombreuses fonctionnalités que l’on pourrait s’attendre à voir dans un langage à usage général. Il s’agit tout simplement d’une fonctionnalité intéressante qui n’a pas été ajoutée à la langue et ne le sera probablement pas. Ce n'est pas une langue morte donc il y a de l'espoir, mais je ne serais pas optimiste.

Comme d'autres l'ont souligné, certaines implémentations utilisent une extension où join (colonne) joint deux tables en fonction d'un nom de colonne commun, qui est assez similaire. Mais ce n'est pas très répandu. Notez que cette extension est différente de la SELECT * FROM employee NATURAL JOIN department;syntaxe qui n'inclut pas un moyen de spécifier les colonnes à utiliser. Aucune des deux ne repose sur une relation entre les tables, ce qui les rend peu fiables (la syntaxe de jointure naturelle est plus importante que l'extension).

Il n'y a pas d'obstacle fondamental à la "table de jointure interne sur PKFK", où PKFK est un mot clé qui signifie "la relation de clé étrangère définie entre les deux tables". Il peut y avoir des problèmes avec plusieurs fk dans la même table, mais cela peut simplement provoquer une erreur. La question est de savoir si les concepteurs de la langue considèrent a) une bonne idée et b) de travailler mieux que d’autres changements de langue ...


3
Cela suppose que c'est une bonne idée qu'ils l'aient déjà fait. Il est également probable qu'ils l'aient déjà envisagé et décidé de ne pas le faire. C'est peut-être une très mauvaise idée dans la pratique: Sjoerd a cité un exemple, dans lequel une requête pourrait être interrompue simplement en ajoutant une nouvelle colonne et une relation FK. Lord Tydus explique également que les clés étrangères ont une responsabilité différente de celle de la manière dont vos tables doivent être reliées.

1
@ JonathanHobbs: Je voulais que ma réponse soit généralement neutre.Mais abandonner la neutralité.La logique de Slayer est erronée.Les changements de tables cassent déjà des requêtes, l'ajout d'une nouvelle colonne à une clé primaire va interrompre les requêtes ou renvoyer des résultats incorrects. En fait, cela vous isolerait dans une certaine mesure, tant que la relation de table était maintenue, les modifications de colonne pourraient être effectuées en toute sécurité. Cela augmenterait probablement l'utilisation des relations FK, car cela serait utile pour autre chose que RI.La plupart des jointures sont soit sur la PK, soit incluent le Pk. Pour gérer plusieurs fk, utilisez le nom de la colonne.
Jmoreno

1

Si l'omission de la clause ON est supposée suivre les champs en fonction de l'intégrité référentielle, comment feriez-vous un produit cartésien?

Edit: using AUTO Les avantages de cette méthode sont un peu moins de frappe et vous n'avez pas besoin de savoir comment ils sont joints ou de vous souvenir d'une jointure compliquée. Si la relation change, elle est traitée automatiquement, mais cela se produit rarement, sauf au début du développement.

Ce que vous devez faire maintenant est de décider si toutes vos jointures AUTO sont bloquées lors d’un changement de relation pour correspondre à l’intention de votre instruction select.


1
@JeffO: le principal avantage est qu'il exprime l'intention plus précisément, d'une manière déclarative très claire. Les jointures de noms de colonnes ne vous disent rien, mis à part le fait que certains contenus des colonnes sont similaires à ceux d'une autre (mais peuvent ne pas être du même type). Une jointure sur un ref fk, vous dit qu'il y a un ref fk, aucune liste de colonne signifierait il n'y avait que 1 fk entre les tables, ou à l' inverse qu'il ya 1+ (considérer une clé multicolumn avec plus de 1 ref ce qui se passe quand vous mélangez les colonnes c1 = fk1_c1 et c2 = fk2_c2). Même avec plus de frappe en moyenne, ce serait bien.
Jmoreno

Utiliser (INNER) JOIN sans ON n’est pas du SQL standard. Virgule, CROSS JOIN & (INNER ou tout OUTER) JOIN ON 0 = 0 retourne un produit cartésien.
philipxy

-1

pourquoi la base de données ne peut-elle pas comprendre que si je joins ces tables, je veux les rejoindre sur les colonnes pk / fk?

Les parties de la raison sont:

1 - en théorie, vous pouvez joindre des tables sur des colonnes arbitraires des deux tables. Bien que ce ne soit pas une pratique courante, cela reste valable. Rappelez-vous que SQL est comme un langage de programmation, il ne comprend pas quelles informations se trouvent dans les colonnes de cours et les noms, en SQL, ne veulent pas dire grand chose à cet égard.

2 - Il existe différents types de jointures (gauche, droite, interne) - Inner Joins n’est que l’un d’eux.

3 - Le standard SQL peut être guidé par le principe d'être un langage de niveau inférieur qui permet aux dialectes de niveau supérieur de former une intelligence en l'utilisant. La comparaison est un peu plus claire si vous pensez à un langage de 4ème génération par rapport à un langage de 3ème génération. En fait, un outil que j'ai utilisé, IEF, vous a permis d'écrire quelque chose comme ceci:

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

En résumé, votre suggestion est intéressante et pourrait être implémentée dans le cadre d'une procédure standard ou stockée (par défaut, une jointure interne).


-10

Tiddo, je pense que vous avez tout à fait raison, SQL sur ce sujet est assez stupide , et je me souviens d'avoir pensé la même chose que vous avez fait avec les clés étrangères lors de l'apprentissage de SQL il y a une dizaine d'années.

Ok, étant donné que, j'ai finalement dû passer cet examen; et pour le réussir, je devais lâcher prise . SQL est plus un naufrage que tout le monde est susceptible de l'admettre, son chemin de standardisation est un désastre complet et certaines implémentations sont menaçantes et complètes . C'est quand même assez pratique, en général. (Je ne suis pas un luddite K / V)

Les clés étrangères, alors ... pas si pratique que ça. C'est un concept important dans le modèle relationnel , d'accord, mais la fonctionnalité SQL portant le même nom ne se compare pas bien.

Dites - vous droit: ne pas utiliser cette fonctionnalité SQL appelé Foreign Keyà tous , jusqu'à ce que vous frappez quelques gros système avec des problèmes de performance. Indiquer explicitement au moteur quel champ est une clé étrangère et non pas, est uniquement utilisé pour l'indexation et est invisible pour l'utilisateur de la base de données.

Est-ce trompeur?
Oui.

Est-ce qu'ils vont le rendre plus puissant maintenant, après 30 ans de tromperie?
Aucune chance.

Ignorer complètement les clés étrangères jusqu'à ce que nécessaire ... SQL fixé pour moi?
Oui!

Et pourquoi diable tout cela est arrivé en premier lieu?
La fonctionnalité que nous appelons clés étrangères a été ajoutée ultérieurement à SQL; SQL est une norme qui a évolué dans le temps, de bas en haut. Les fournisseurs ont implémenté des fonctionnalités ridicules, alors que les corps standard ont une apparence faciale.

Comme indiqué précédemment, les clés étrangères étaient uniquement destinées à l'indexation et il n'y avait pas de construction JOIN disponible. (les jointures sont effectuées avec des SELECTrequêtes, celles-ci JOINsont relativement récentes et ne visent qu'à aliaser la SELECTfonctionnalité) Ils ont probablement pensé que l'appelant cet indicateur d'indexation FOREIGN KEYétait un habile nommage-piratage des concepts de la théorie de la base de données relationnelle.


13
En ce qui concerne les clés étrangères, je suppose que vous n’avez jamais touché au moteur MyISAM sur MySQL? Parce que même en faisant abstraction de ce petit discours, chaque réponse de cette réponse est fausse.

Les Fk ne sont pas utilisés pour l'indexation. En fait, un problème courant est de ne pas avoir d'index sur la colonne fk, ce qui peut avoir un impact considérable sur les performances.
jmoreno le
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.