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

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.

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.

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.

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.

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.

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.

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.

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!)

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?

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 ...

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.

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).

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.