1. Accueil
  2. Question et réponse
  3. Sql Type de données pour la clé primaire - SQL Server?

Sql Type de données pour la clé primaire - SQL Server?

2008-11-01 7 views

Répondre

46

En général, int.

bigint si vous pensez que vous aurez plus de lignes que d'atomes dans l'univers.

uniqueidentifier est utile si vous avez besoin globalement clés uniques (clés qui sont garantis pour être unique dans toutes les tables de votre schéma, peut-être même unique universel (je ne me souviens pas))

Les deux autres I n'utiliserait pas ils ne sont pas des types intégraux (ils ont des fractions, qui n'ont tout simplement pas beaucoup de sens en tant que clés)

Source

2008-11-01 05:57:07

+4

Si vous choisissez un identifiant unique, pensez à en faire une clé primaire NON CLUSTERED, sinon les insertions peuvent avoir des problèmes de performances. – Brannon

+0

Merci pour la mise à niveau, Brannon. –

+2

int est limité «seulement» autour de 2 milliards. J'ai déjà atteint cette limite avec certaines fonctionnalités de journalisation;) – Mose

2

Une raison majeure pour ne pas utiliser les GUID pour les PK est leur taux de remplissage terrible pour les pages d'index - une telle mauvaise utilisation peut considérablement augmenter vos coûts de performance d'E/S. Les GUID doivent être laissés comme des AK et à la place conduire des requêtes avec des PK dérivés int si possible.

Source

2008-11-01 06:05:25 stephbu

+7

C'est vraiment un peu inexact - GUID comme PK est OK - GUID comme la CLUSTERING KEY est un desaster. Le PK en soi n'a aucun effet sur l'organisation physique des données - c'est le travail de la clé de clustering :) –

0

pour les processeurs 32 bits, un int est susceptible d'être la taille la plus efficace pour le traitement.

Source

2008-11-01 06:10:27 dkretz

+1

Les limites de mots sont moins pertinentes que l'espace occupé passant de Int à BigInt - sauf si vous attendez un nombre de lignes de plusieurs milliards, sauf row octets et les dépenser ailleurs. Le coût d'E/S est plusieurs ordres plus chers que l'accès à la mémoire. – stephbu

+0

D'accord, je viens d'ajouter une autre raison d'utiliser int. – dkretz

20

Vous avez vraiment besoin de garder deux questions distinctes: à part

1) la clé primaire est une construction logique - l'un des candidats clés qui identifie de façon unique et fiable d'une ligne dans votre table. Cela peut être quelque chose, vraiment - un INT, un GUID, une chaîne - choisissez ce qui est le plus logique pour votre scénario.

2) regroupement clé (la colonne ou des colonnes qui définissent le « index cluster » sur la table) - c'est un physique chose liée au stockage, et ici, une petite, stable, toujours plus Le type de données est votre meilleur choix - INT ou BIGINT comme option par défaut.

Par défaut, la clé primaire d'une table SQL Server est également utilisée comme clé de clustering - mais cela n'est pas nécessaire! Personnellement, j'ai l'impression de gains de performances massifs au fil du temps lors de la décomposition de la clé Clustered principale GUID précédente en deux clés distinctes: la clé principale (logique) du GUID et la clé de clustering (ID) , 1) colonne.

La fragmentation de l'index était réduite à des niveaux minimaux, et donc la performance de recherche d'index était en hausse - fortement recommandé!

Marc

Source

2009-01-28 21:56:20

+0

Ouais tout à fait d'accord Marc - il est assez rare pour les gens moyens de voir au-delà des outils de création de diagrammes, et c'est si facile de faire un clic droit, mettre PK ... – stephbu

+0

Très utile, merci de partager! – Martin

1

unsigned int de taille selon qui répond à vos besoins particuliers

Source

2009-01-28 22:00:01

+6

Sauf que le serveur SQL n'a pas de type de données non signé. – Joe

Questions connexes

 Questions connexes