Une clé primaire est-elle nécessaire dans SQL Server?

Avez-vous des clés étrangères, avez-vous déjà rejoint sur le PK?

Si la réponse est non, et que votre application ne récupère jamais un élément de la table par son PK, et qu'aucune requête ne l'utilise dans une clause where, vous venez donc d'ajouter une colonne IDENTITY pour avoir un PK, alors:

• Le PK en lui-même n'ajoute aucune valeur, mais ne fait aucun dommage non plus
• le fait que le PK soit très probablement l'index clusterisé l'est aussi .. Cela dépend .

Si vous avez des index NC, alors le fait que vous ayez une clé artificielle en cluster étroite (L'identité PK) est utile pour garder ces index étroits (la clé CDX est reproduite dans chaque emplacement de feuille NC). Donc, un PK, même s'il n'est jamais utilisé, est utile si vous avez des index NC significatifs.

D'autre part, si vous avez un modèle d'accès répandu, une certaine requête qui l'emporte sur toutes les autres est la fréquence et l'importance, ou qui fait partie d'un chemin de code temporel critique (par exemple. la requête est-elle exécutée à chaque visite de page sur votre site, ou chaque seconde par et app etc) alors cette requête est un bon candidat pour dicter l'ordre des clés en cluster.

Et enfin, si la table est rarement interrogée mais souvent écrite, elle peut être un bon candidat pour un tas (pas de clé clusterisée du tout) car les tas sont tellement meilleurs aux insertions. Voir comparaison des Tables organisées avec des index en cluster par rapport aux tas .

La clé primaire est dans les coulisses un clustered index (par défaut, sauf si elle est générée en tant qu'index non clusterisé) et contient toutes les données de la table. Si le PK est une colonne d'identité, les insertions se produiront séquentiellement et aucune division de page ne se produira.

Mais si vous n'ACCÉDEZ PAS du tout à la colonne id, vous voudrez probablement ajouter des index sur les autres colonnes. De plus, lorsque vous avez un PK, vous pouvez configurer les relations FK

Dans le modèle logique, une table doit avoir au moins une clé. Il n'y a aucune raison de spécifier arbitrairement que l'une des clés est 'primaire'; toutes les clés sont égales. Bien que le concept de "clé primaire" remonte aux premiers travaux de Ted Codd, l'erreur a été reprise tôt a longtemps été corrigée dans la théorie relationnelle.

Malheureusement, PRIMARY KEY trouvé son chemin dans SQL et nous avons dû vivre avec depuis. Les tables SQL peuvent avoir des lignes en double et, si vous considérez le resultset d'un SELECT requête pour être également une table, alors les tables SQL peuvent aussi avoir des lignes dupliquées. Les théoriciens relationnels n'aiment pas beaucoup SQL. Cependant, juste parce que SQL vous permet de faire toutes sortes de choses non relationnelles farfelues, cela ne signifie pas que vous devez réellement les faire. Est une bonne pratique pour s'assurer que chaque table SQL a au moins une clé.

En SQL, l'utilisation de PRIMARY KEY seule a des implications, par exemple NOT NULL, UNIQUE, référence par défaut de la table pour les clés étrangères. Dans SQL Server, l'utilisation de PRIMARY KEY seule a des implications par exemple, l'index clusterisé de la table. Cependant, dans tous ces cas, le comportement implicite peut être rendu explicite en utilisant une syntaxe spécifique.

Vous pouvez utiliser UNIQUE (contrainte plutôt que index) et NOT NULL en combinaison pour appliquer les clés dans SQL. Par conséquent, non, une clé primaire (ou même PRIMARY KEY) n'est pas nécessaire dans SQL Server.

Je n'aurais jamais de table sans clé primaire. Supposons que vous ayez besoin de supprimer un doublon-comment identifieriez-vous celui à supprimer et celui à conserver?

La clé primaire Une fois définie aidera à améliorer les performances dans la base de données pour l'indexation et les relations.

J'ai toujours tendance à définir une clé primaire comme un entier incrémenté automatiquement dans toutes mes tables, que j'y accède ou non, c'est parce que lorsque vous commencez à mettre à l'échelle votre application, vous pouvez en avoir réellement besoin, et cela rend la vie beaucoup plus simple.

Clé primaire est vraiment une propriété de votre modèle de domaine, et il identifie de manière unique une instance d'un objet de domaine.

Avoir un index clusterisé sur une colonne montoniquement croissante (comme une colonne d'identité) signifiera que les divisions de page ne se produiront pas, mais les insertions déséquilibreront l'index au fil du temps et donc la reconstruction des index doit être effectuée régulièrement (ou lorsque la fragmentation atteint un certain seuil).

Je dois avoir une très bonne raison pour créer une table sans clé primaire.

Si vous y accédez via des champs non-clés, les performances ne changeront probablement pas. Cependant, il pourrait être bon de garder le PK pour de futures améliorations ou interfaces à ces tables. Votre application utilise-t-elle uniquement cette table?

Comme L'a dit SQLMenace, L'index clusterisé est une colonne importante pour la disposition physique de la table. De plus, avoir un index cluster, en particulier un index bien choisi sur une colonne maigre comme un entier pk, augmente réellement les performances d'insertion.

Un PK n'est pas nécessaire.

Mais vous devriez envisager de placer un index non unique sur les colonnes que vous utilisez pour interroger (c'est-à-dire qui apparaissent dans la clause WHERE). Cela augmentera considérablement les performances de recherche.