Pourquoi sont-clés étrangères plus utilisé dans la théorie que dans la pratique?

La raison de contraintes de clés étrangères existe, est de garantir que les lignes référencées existent.

"La clé étrangère identifie une colonne ou un ensemble de colonnes dans une table qui fait référence à une colonne ou un ensemble de colonnes d'une autre table. Les valeurs d'une ligne de référence colonnes doivent avoir lieu dans une seule ligne dans la table référencée.

Ainsi, une ligne dans la table de référence ne peut pas contenir de valeurs qui n'existent pas dans la table référencée (sauf éventuellement NULLE). De cette façon, les références peuvent être faites à la liaison d'informations et il est une partie essentielle de normalisation de base de données." (Wikipédia)

---

RE: Votre question: "je ne peux pas imaginer la nécessité de joindre des tables de champs qui ne sont pas FKs":

Lors de la définition d'une contrainte de Clé Étrangère, la colonne(s) dans la table de référence doit être la clé primaire de la table référencée, ou au moins une clé candidate.

Quand vous faites des jointures, il n'y a pas besoin de se joindre avec des clés primaires ou candidat clés.

Ce qui suit est un exemple qui pourrait faire sens:

CREATE TABLE clients (
    client_id       uniqueidentifier  NOT NULL,
    client_name     nvarchar(250)     NOT NULL,
    client_country  char(2)           NOT NULL
);

CREATE TABLE suppliers (
    supplier_id       uniqueidentifier  NOT NULL,
    supplier_name     nvarchar(250)     NOT NULL,
    supplier_country  char(2)           NOT NULL
);

Et puis la requête comme suit:

SELECT 
    client_name, supplier_name, client_country 
FROM 
    clients 
INNER JOIN
    suppliers ON (clients.client_country = suppliers.supplier_country)
ORDER BY
    client_country;

Un autre cas où ces jointures sens est dans la base de données géospatiales de fonctionnalités, comme SQL Server 2008 ou Postgres avec PostGIS. Vous serez en mesure de faire des requêtes comme celles-ci:

SELECT
    state, electorate 
FROM 
    electorates 
INNER JOIN 
    postcodes on (postcodes.Location.STIntersects(electorates.Location) = 1);

Source: ConceptDev - SQL Server 2008 Géographie: STIntersects, STArea

Vous pouvez en voir un autre similaire géospatiales exemple dans la accepté de répondre à ce poste "Sql 2008 requête problème qui LatLong du existe dans une géographie polygone?":

SELECT 
    G.Name, COUNT(CL.Id)
FROM
    GeoShapes G
INNER JOIN 
    CrimeLocations CL ON G.ShapeFile.STIntersects(CL.LatLong) = 1
GROUP BY 
    G.Name;

Ce sont toutes valides jointures SQL qui n'ont rien à voir avec les clés étrangères et candidat clés, et peut encore être utile dans la pratique.

Je ne peux pas imaginer la nécessité de joindre des tables de champs qui ne sont pas FKs. Quelqu'un peut-il donner un exemple qui fait sens?

FOREIGN KEYs ne peut être utilisé pour appliquer l'intégrité référentielle si la relation entre les entités de la ER modèle se manifeste avec une équi-jointure entre deux relations dans le modèle relationnel.

Ce n'est pas toujours vrai.

Voici un exemple tiré de l'article de mon blog que j'ai écrit il y a quelques temps:

• Quel est le modèle entité-relation?

Ce modèle décrit les produits et les gammes de prix:

Et voici le relationnel de la mise en œuvre du modèle:

CREATE TABLE Goods (ID, Name, Price)
CREATE TABLE PriceRange (Price, Bonus)

Comme vous pouvez le voir, le PriceRange tableau n'a qu'un seul prix d'attributs, Price, mais le modèle a deux attributs: StartPrice et EndPrice.

C'est parce que le modèle relationnel permet de transformer les décors et l'entité PriceRange peut facilement être reconstruits à l'aide de SQL opérations.

Goods
ID  Name               Price
1   Wormy apple        0.09
2   Bangkok durian     9.99
3   Densuke watermelon 999.99
4   White truffle      99999.99

PriceRange
Price   Bonus
0.01       1%
1.00       3%
100.00    10%
10000.00  30%

Nous ne disposons que la limite inférieure de chaque plage. La limite supérieure peut être facilement déduite.

Voici la requête pour trouver les bonus pour chaque bien:

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

Nous voyons que ces modèle relationnel met en œuvre le ER modèle assez bien, mais pas de clé étrangère peut être déclarée entre ces relations, depuis l'opération permet de lier entre eux n'est pas une équi-jointure.

Vous pouvez vous joindre à n'importe quelle expression. Si vous définissez les clés étrangères dans votre base de données ou pas est sans importance. Les clés étrangères contraindre INSERT/UPDATE/DELETE, SÉLECTIONNEZ pas.

Alors pourquoi faire beaucoup de projets de sauter la définition des clés étrangères? Il y a plusieurs raisons:

• Le modèle de données est conçue de façon médiocre et nécessite des références incorrectes (exemples: polymorphe associations, VAE).

• Les codeurs ont peut-être entendu que "les clés étrangères sont lents", de sorte qu'ils tombent d'eux. En fait, le travail supplémentaire que vous avez à faire pour garantir la cohérence des données lorsque vous ne pouvez pas compter sur les clés étrangères rend votre application beaucoup moins efficace. L'optimisation prématurée, sans réellement mesurer le profit est un problème commun.

• Contraintes obtenir de la manière de certaines données des tâches de nettoyage. Parfois, vous avez besoin pour briser les références temporairement comme vous refactoriser de données. De nombreux SGBDR permettre à des contraintes pour les handicapés, mais parfois, les programmeurs de décider qu'il est plus facile de laisser handicapé. Si il y a un besoin fréquent pour désactiver les contraintes, cela indique probablement un brisé conception de base de données.

Parce que, dans la pratique, la théorie n'est pas assez 😉

Sérieusement, dans mon expérience est principalement parce que la théorie n'est pas assez souple pour envisager toutes les possibilités que vous avez à gérer dans le monde réel. Seulement avec un très étrange affaire que vous avez à stocker dans votre base de données (ou quelque chose de plus commun, comme la surcharge des colonnes de), vous devez sortir de la FK et de mettre en œuvre dans le DAL.

Peut-être vous pouvez développer une solution qui peut être archivé dans un cadre totalement normalisé (par exemple), mais dans de nombreux cas, les travaux nécessaires et/ou les résultats de la finale de valeur n'est pas suffisante.

Mes deux cents.

Les clés étrangères ne sont pas utilisés aussi souvent que la théorie relationnelle suggère parce que DB/type relationnel gens ne sont pas d'écrire beaucoup de code ou même concevoir les tables. Les programmeurs écrivent du code/design tables ou avoir beaucoup d'influence sur la façon dont les tables sont conçues.

Les clés étrangères sont extrêmement importants, en particulier dans les bases de données manuel de requêtes exécutées sur eux, ou avoir un logiciel développé pour eux. Tous les non testé requête est exécutée sur la base de données a la possibilité de contenir une erreur. Des contraintes telles que les clés étrangères servent à mettre en évidence ces erreurs avant d'incohérence est introduit dans les données.

Ces contraintes sont appliquées par le concepteur du schéma, et ils s'assurer que les données restent dans le modèle (s)qu'il a envisagées. Si les contraintes ne sont pas là, alors tôt ou tard, une requête d'introduire une certaine incohérence. Incohérence va conduire à des résultats imprévisibles à partir de requêtes, et est très difficile à inverser.

Bonne question. Je me suis toujours demandé pourquoi SQL n'a pas une syntaxe comme

SELECT tbl1.col1, tbl2.col2
  FROM tbl1
  JOIN tbl2 USING(FK_tbl1_tbl2)

où FK_tbl1_tbl2 est certaine contrainte de clé étrangère entre les tables. Ce serait incroyablement beaucoup plus utile que la JOINTURE NATURELLE ou d'Oracle à l'AIDE de colonnes(col1, col2).

Partie pour moi, c'est que (et oui, c'est une piètre excuse) de l'INTERFACE utilisateur de MS SQL Server Management studio pour l'ajout de clés étrangères est terrible.

Une clé étrangère est une contrainte qui "n'importe quelle valeur dans la colonne x sur la table un doit apparaître dans la colonne de y sur la table b", mais l'INTERFACE utilisateur pour le précisant dans SSMS ne pas indiquer clairement quelle table vous êtes de jouer avec, ce qui est le parent de la table, qui est l'enfant de la table, et ainsi de suite.

Chaque fois que j'ai eu à créer une clé étrangère, il a été d'essai et d'erreur jusqu'à ce qu'il semblait fonctionner.

Clé étrangère est couplage. Dans la programmation, le couplage est rarement bon.