Utilisation de contraintes de clé étrangère

clé primaire). Cependant, le référencement d’une clé primaire est plus typique, et constitue généralement une meilleure méthode.

Il n’est pas nécessaire d’utiliser des noms de colonnes identiques dans les tables impliquées dans la référence de clé étrangère, mais c’est souvent conseillé. Considérons une table Customers, référencée par une table Orders. Les colonnes portant les noms cust_id et location_num sont définies dans la table Customers. La table Orders peut utiliser des colonnes s’appelant cust_num et cust_loc, mais la différence de noms de colonne peut entraîner une lourdeur lors du traitement des tables.
Bien que les noms des colonnes liées puissent être différents, les types de données contenues dans les colonnes associées doivent être identiques sauf pour les attributs d’invalidité et de longueur variable. Par exemple, une colonne de type char(10) NON NULLE peut référencer une colonne de type varchar(10) NULLE mais elle ne peut pas référencer une colonne de type char(12) NON NULLE, car la longueur définie est différente dans les deux colonnes. De la même manière, une colonne de type smallint ne peut pas référencer une colonne de type int.
Le propriétaire de la table est un autre élément de clé étrangère à  prendre en considération. Je recommande d’avoir un propriétaire, de préférence celui de la base de données (DBO : DataBase Owner), qui possède toutes les tables d’une base de données. Mais, dans certains cas, cette restriction n’est pas la meilleure solution. Le propriétaire d’une table ne peut pas déclarer une référence de clé étrangère sur une autre table, à  moins que le propriétaire de l’autre table n’ait accordé les droits REFERENCES au propriétaire de la première table. Ce dernier doit avoir les droits REFERENCES, même s’il dispose déjà  d’une autorisation pour sélectionner à  partir de la table à  référencer. Cette restriction empêche un utilisateur d’accéder à  vos tables, sans vous avertir ou sans votre accord, et de modifier la manière dont les opérations sont réalisées. (Si un utilisateur peut créer une clé étrangère référençant une de vos tables, il peut vous être interdit de modifier votre propre table afin de ne pas violer la relation établie par cette autre personne). On peut accorder les droits REFERENCES à  un autre utilisateur, même si on n’accorde pas les droits SELECT, et vice versa. Il existe une seule exception : le DBO, ou tout autre utilisateur membre du rôle db_owner, dispose des droits complets sur tous les objets de la base de données par défaut.
Lorsqu’on utilise des contraintes de clé étrangère, il faut également prendre les performances et l’indexation en considération. Lorsqu’on décide d’utiliser des relations de clé étrangère, on doit trouver un juste milieu entre la protection fournie et la charge supplémentaire induite sur les performances du système. Soyez attentif à  ne pas ajouter de contraintes formant des relations logiquement redondantes. Une utilisation excessive des contraintes de clé étrangère peut dégrader les performances d’opérations apparemment simples.
Les colonnes définies dans des contraintes de clé étrangère constituent souvent de bons candidats pour la création d’index. Si vous concevez l’index avec le même ordre de clé que dans la clé primaire ou dans la contrainte Unique de la table référencée par la clé étrangère, SQL Server peut effectuer des jointures de manière efficace. En outre, une clé étrangère peut représenter un sous-ensemble de la clé primaire de la table. Dans la table Order Details de la base de données Northwind, OrderId fait partie de la clé primaire, et c’est également une clé étrangère. Etant donné que OrderId fait partie de la clé primaire, il fait déjà  partie d’un index. Dans la table Order Details, OrderId est la colonne principale de l’index. Par conséquent, concevoir un index distinct uniquement sur cette colonne n’est probablement pas garanti. Cependant, si OrderId n’était pas la colonne principale de l’index, la conception d’un index basé sur cette colonne pourrait être judicieuse.