SQL Server: clé primaire du schéma Guid mais parfois en grande partie Types entiers

Question

OK, cela peut être une question stupide, mais ...

J'ai hérité d'un projet et je suis chargé d'aller sur les relations de clé primaire.

Le projet utilise principalement Guids. Je dis «en grande partie» parce qu'il existe des exemples où les tables utilisent des types entiers pour refléter les énumérations. Par exemple, dbo.MessageFolder a MessageFolderId de type int pour refléter

public emum MessageFolderTypes 
{ 
    inbox = 1, 
    sent = 2, 
    trash = 3, 
    etc... 
} 

Cela se produit beaucoup. Il existe des tables avec des clés primaires de type int qui sont inévitables en raison de leur dépendance aux énumérations et des tables avec des clés primaires de type Guid qui reflètent le choix de la clé primaire sur la partie du programmeur précédent.

Est-ce que je devrais m'inquiéter que le schéma de PK soit taché comme ceci? Il ne se sent pas bien mais est-ce vraiment important? Si cela peut créer un problème, comment puis-je le contourner (je ne peux vraiment pas déplacer tous les PK pour taper int sans travail sérieux et je n'ai jamais entendu parler d'énumérations qui ont des valeurs guid)?

Merci.

Answer 1

Qu'est-ce que vous pourriez faire pour une « victoire rapide » est la suivante:

• quitter la clé primaire comme il est (avantage: vous n'avez pas besoin de modifier les contraintes d'intégrité référentielle)
• mais que votre clé primaire GUID une non-cluster clé primaire
• mettre la clé de cluster sur un champ distinct - utiliser quelque chose qui est déjà disponible, s'il y a un champ utile - ou sinon, utilisez un champ d'identité INT

L'amélioration des performances que vous obtiendriez avec une bonne clé de clustering peut être très significative! Pas seulement quelques pour cent - plusieurs ordres de grandeur.

Lire ici pourquoi GUIDs as Primary Key (en fait: comme clé de cluster) sont un choix horriblement mauvais, et lire ici The Clustered Index Debate - Again! ce qu'est une bonne clé de regroupement devrait être comme - idéalement:

• étroite (comme quelques octets possible)
• statique (ne change jamais)
• uniques (sinon SQL Server devra « uniquify » vos entrées en ajoutant 4 octets à eux)
• toujours plus (pour éviter des ruptures de page coûteuses et de réduire la fragmentation des index/page)

INT IDENTITY est un candidat idéal.

Answer 2

Idéalement, vous vous éloignez des GUID comme PK, en raison de la performance - Mais je comprends que ce soit impossible.

La performance GUID est bien aménagé ici: What are the performance improvement of Sequential Guid over standard Guid?

Je ne vous inquiétez pas au sujet de la spottiness, si vous utilisez la plus petite clé que vous pouvez alors vous êtes tenus d'avoir plusieurs types de données différentes PKS dans un DB (TinyInt/SmallInt/Int/BigInt).

Answer 3

Ce qui compte le plus, c'est que toutes les clés nécessaires pour assurer l'intégrité sont appliquées. Il n'y a aucune raison réelle pour laquelle le même type de colonne doit être utilisé comme clé dans chaque table. On peut supposer que vous avez d'autres clés (naturelles) imposées par des contraintes/index uniques et si c'est le cas, je m'attendrais à ce que certaines d'entre elles incluent des colonnes qui ne sont pas des entiers ou des guids.