Chaque table devrait-elle avoir une clé primaire de substitution / artificielle à champ unique?

Je comprends un avantage des clés de substitution / artificielles en général - elles ne changent pas et cela peut être très pratique. Cela est vrai, qu’il s’agisse d’un seul ou de plusieurs domaines, pour autant qu’ils soient «artificiels».

Cependant, il semble parfois que le fait d’avoir un champ entier auto-incrémenté comme clé primaire de chaque table semble être une question de politique. Est-ce toujours la meilleure idée d'avoir une clé à un seul champ et pourquoi (ou pourquoi pas)?

Pour être clair, cette question ne concerne pas l’art artificiel ou naturel, mais la question de savoir si toutes les clés artificielles doivent être à champ unique.

Je vais dire non, pas toujours, mais la plupart du temps oui. .

Voici certaines circonstances dans lesquelles vous n'avez pas besoin de clé de substitution ou de clé artificielle:

• Tables d'intersection pure . S'il n'y a aucun risque que l'intersection soit la cible d'une clé étrangère et si elle risque peu ou pas d'attirer des attributs indépendants (c'est-à-dire autre chose que FK dans les deux tables parent), vous pouvez vous en tirer avec la combinaison des FK comme PK avec une confiance raisonnable.
• Tables de recherche avec des clés métier statiques . Si vous disposez d'une
  table de recherche avec une clé unique, fixée de manière externe à votre
  entreprise et qui n'a aucune chance de changer pour quelque
  raison que ce soit, l'utilisation de la clé directement peut vous
  simplifier la tâche. Un exemple pourrait être une liste de
  codes d’états ou de provinces ou une liste de numéros normalisés ANSI, etc.
• Tableaux contenant des données consolidées à partir de plusieurs sources indépendantes . Si votre système contient de nombreuses sources de données qui doivent être regroupées dans une seule table, par exemple au siège social, il vous faut parfois une clé composée qui inclut la valeur de la clé du système source et un code indiquant son état actuel.

Il existe également des situations dans lesquelles la clé de substitution à nombre entier croissante monotone fidèle n’est pas idéale. Vous pouvez avoir des clés qui sont des substituts alphanumériques. Ceux-ci pourraient inclure:

• Situations dans lesquelles vous devez fusionner des données provenant de plusieurs sources indépendantes. Pour éviter les conflits de clé, vous pouvez utiliser des GUID au lieu de clés IDENTITY.
• Situations dans lesquelles vous êtes obligé d'utiliser des représentations de clé non numériques. Disons que vous avez une base de données de plaques d'immatriculation. Votre clé pourrait être la valeur alphanumérique au lieu d’un nombre pur.
• Situations dans lesquelles des exigences externes vous obligent à appliquer une compression à votre valeur de clé. Au lieu d'utiliser 10 chiffres pour un int32, vous pouvez utiliser six chiffres de base 36.

Pourquoi la plupart du temps oui? La réponse la plus fondamentale à cette question est que c'est du pur enfer si vous devez modifier une valeur de clé primaire sur une table. Étant donné que presque tout ce qu'un utilisateur peut voir ou toucher est susceptible d'une mise à jour à un moment donné, l'utilisation d'une valeur de clé visible invite à un véritable enfer. L'utilisation d'une clé de substitution vous évitera de tomber dans ce piège.

Cela dit, souvenez-vous que YAGNI a toute latitude pour appliquer ce concept. Vous n'avez pas besoin de forcer des tables de code avec des clés IDENTITY dans chaque coin de votre schéma, juste au cas où quelqu'un déciderait que le symbole du genre masculin dans votre table d'employé doit changer de M à X ou quelque chose de stupide.

Non.

Je dirais qu'il y a certainement des cas où les clés à un seul champ sont inférieures aux clés composées, du moins pour les clés étrangères . Cela ne veut pas dire que vous ne devriez pas avoir de clé de substitution à champ unique si vous préférez, mais je préfère personnellement que la clé qui est le plus souvent utilisée comme cible d'une clé étrangère soit appelée clé primaire.

Je vais essayer d’illustrer mon propos dans les exemples suivants, dans lesquels:

• brand est une marque de voiture, par exemple Ford, Toyota, etc.
• dealer est un concessionnaire physique lié à une marque (par exemple, un concessionnaire Ford vendant uniquement des Ford)
• model est le type de voiture, par exemple Ford Focus, Ford Fiesta, etc.
• stock est le nombre actuel de voitures de parc pour chaque concessionnaire

Si nous créons une clé de substitution à champ unique pour dealeret modelcomme suit:

create table brand( brand_id integer primary key );

create table dealer( dealer_id integer primary key, 
                     brand_id integer references brand )

create table model( model_id integer primary key, 
                    brand_id integer references brand )

create table stock( model_id integer references model, 
                    dealer_id integer references dealer, 
                    quantity integer,
                      primary key(model_id, dealer_id) )

alors il est possible d'insérer une rangée dans stockqui relie une Ford dealerà un modèle "Toyota". Ajouter brand_id references brandà stockne fait qu'aggraver le problème. Par ailleurs, si nous conservons la clé étrangère dans la clé primaire comme suit:

create table brand( brand_id integer primary key );

create table dealer( brand_id integer references brand, 
                     dealer_id integer, 
                       primary key(brand_id, dealer_id) )

create table model( brand_id integer references brand, 
                    model_id integer, 
                      primary key(brand_id, model_id) )

create table stock( brand_id integer, 
                    model_id integer, 
                    dealer_id integer, 
                    quantity integer,
                      primary key(brand_id, model_id, dealer_id),
                      foreign key(brand_id, model_id) references model,
                      foreign key(brand_id, dealer_id) references dealer )

maintenant, la règle selon laquelle les concessionnaires "Ford" ne peuvent stocker que des voitures "Ford" est naturellement appliquée par le modèle.

Notez que dans l'exemple «clés composites», il dealer_idest possible que les préférences soient uniques ou non. Il n’est pas nécessaire qu’il soit unique (c’est-à-dire une clé alternative), mais vous perdez très peu de choses (peut-être un peu d’espace de stockage) et cela peut être très pratique, c’est ainsi que je l’utilise habituellement, par exemple:

create table dealer( brand_id integer references brand, 
                     dealer_id serial unique, 
                       primary key(brand_id, dealer_id) )

"ça dépend"

Oui: les champs IDENTITY / AUTONUMBER de substitution sont bons lorsque la clé naturelle est large et non numérique. Remarque: cela suppose la fusion de "PK" et de l'index clusterisé qui se produit par défaut dans SQL Server et Sybase, etc.

Non: plusieurs / plusieurs tables lorsque les 2 clés parent suffisent. Ou lorsque la clé naturelle est courte et de longueur fixe, par exemple un code de devise

Bien sûr, un ORM sans tête (lire: (H) Hibernate) peut outrepasser ces règles ...

Edit: relire la question

Une table plusieurs / plusieurs avec 2 clés parent de substitution aura une PK à plusieurs colonnes.
Cependant, il n'a pas besoin d'une autre colonne de substitution.

Si une table a une clé de substitution (IDENTITY, etc.), il n'est pas nécessaire qu'elle soit composée de plusieurs colonnes.

Vous pouvez avoir une super clé qui inclut le substitut, mais ce serait pour appliquer d'autres règles (par exemple, des sous-types ).