Good Database-Design n'a pas de colonnes d'identité dans les tables, n'est-ce pas?

Question

quel est l'avantage d'avoir une colonne d'identité supplémentaire dans chaque table d'une base de données? Quels sont les inconvénients?

Mise à jour: Maintenant, je veux étendre le cas et introduire la réplication. Pour quoi est cette clé de surogate (identité comlumn) à part le rowguid que nous obtenons avec la réplication. Au nom de l'objection de K. Brian Kelley, il faut définir l'index clusterisé sur ce rowguid (et oublier la colonne identity). Qu'est-ce que tu penses?

Answer 1

Souvent, l'utilisation de clés de substitution, dont les colonnes IDENTITY sont les plus courantes, est souvent effectuée pour des raisons de performances. Vous devez toujours identifier les clés naturelles (les colonnes qui rendent la ligne unique en fonction des données).

Généralement, les clés de substitution sont des valeurs entières. Cela les rend faciles à relier en utilisant des jointures avec d'autres tables (et restreindre en conséquence en utilisant des clés étrangères). En outre, lorsque vous parlez de SQL Server, tous les index non clusterisés dépendent de l'index clusterisé. Ainsi, si l'index clusterisé est basé sur la clé naturelle et que sa taille est conséquente, tous les index non clusterisés seront également importants, car ils renverront à l'index clusterisé. Par conséquent, beaucoup de gens construisent la clé primaire autour de cette clé de substitution à base d'entiers. Je sais que je simplifie un peu, mais c'est une raison clé pour l'utilisation de clés de substitution.

L'inconvénient est que la clé de substitution est effectivement sans signification. Si quelqu'un devait modifier la valeur de la clé, vous pourriez rompre une relation si les contraintes de clé étrangère ne sont pas présentes ou sont désactivées. Dans le cas d'une modification qui modifie la clé de remplacement, vous modifiez réellement les données elles-mêmes. Donc, vous vous attendez à une telle rupture si les entités sont construites correctement et que vous modifieriez également les données des tables connexes.

Answer 2

Version courte: La clé de substitution ou synthétique (ce que vous entendez probablement par "colonne d'identité") par rapport à la clé naturelle est un très vieux débat.

Pour de clés de substitution:

• vous fait indépendante des changements dans la clé naturelle (pensez nouvelles exigences/changement de modèle de domaine), qui autrement en cascade par votre modèle de données
• parfois, il est aucune clé naturelle (par exemple des personnes dans un carnet d'adresses)
• est souvent plus rapide, car il est plus court (seule colonne int, au lieu de plusieurs, par exemple varchars)
• est plus pratique dans les jointures, etc. becau se il est seulement une seule colonne

Moins:

• vous avez encore besoin d'un index unique pour chaque candidat clé naturelle (donc un plus index nécessaire)
• il est étranger au domaine, et peut exiger une jointure supplémentaire pour obtenir les données réelles

Généralement, l'accord est que les clés de substitution sont généralement une bonne idée, sauf dans des cas simples comme les tables jointes.

Pour tous les détails, voir Wikipedia, qui a un bon article sur le sujet.