Confusion t-sql examen réponse sur la séquence ou uniqueidentifier

J'ai trouvé une question t-sql et sa réponse. C'est trop confus. Je pourrais utiliser un peu d'aide.

La question est:

Vous développez une application de database. Vous créez quatre tables. Chaque table stocke différentes catégories de produits. Vous créez un champ Clé primaire sur chaque table.

Vous devez vous assurer que les conditions suivantes sont remplies:

  • Les champs doivent utiliser le minimum d'espace.
  • Les champs doivent être une série incrémentielle de valeurs.
  • Les valeurs doivent être uniques parmi les quatre tables.

Que devrais tu faire?

  • A. Créez une colonne ROWVERSION .
  • B. Créez un object SEQUENCE qui utilise le INTEGER données INTEGER .
  • C. Utilisez le INTEGER données INTEGER avec IDENTITY
  • D. Utilisez le type de données NEWSEQUENTIALID() avec NEWSEQUENTIALID()
  • E. Créez une colonne TIMESTAMP .

La réponse est D. Mais, je pense que la réponse la plus appropriée est B. Parce que la séquence utilisera less d'espace que GUID et répond à toutes les exigences.

D est une mauvaise réponse, car NEWSEQUENTIALID ne garantit pas "une série de valeurs incrémentielles" (deuxième exigence).

NEWSEQUENTIALID()

Crée un GUID supérieur à tout GUID précédemment généré par cette fonction sur un ordinateur spécifié depuis le démarrage de Windows. Après avoir redémarré Windows, le GUID peut recommencer à partir d'une plage inférieure , mais rest globalement unique.

Je dirais que B ( sequence ) est la bonne réponse. Au less, vous pouvez utiliser une sequence pour remplir les trois conditions, si vous ne le redémarrez pas / le recyclez manuellement. Je pense que c'est la façon la plus simple de répondre aux trois exigences.

Entre les choix fournis, D B est la bonne réponse, car elle répond à toutes les exigences:

ROWVERSION est un mauvais choix pour une key primaire, comme indiqué dans MSDN :

Chaque fois qu'une ligne avec une colonne rowversion est modifiée ou insérée, la valeur rowversion de la database incrémentée est insérée dans la colonne rowversion. Cette propriété fait d'une colonne rowversion un mauvais candidat pour les keys, en particulier les keys primaires. Toute mise à jour apscope à la ligne modifie la valeur rowversion et, par conséquent, modifie la valeur de la key. Si la colonne est dans une key primaire, l'ancienne valeur de key n'est plus valide et les foreign keys faisant reference à l'ancienne valeur ne sont plus valides.

TIMESTAMP est déprécié, comme indiqué dans cette même page:

La syntaxe d'horodatage est obsolète. Cette fonctionnalité sera supprimée dans une future version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans les nouveaux travaux de développement et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.

Une colonne IDENTITY ne garantit pas l'unicité, à less que toutes ses valeurs soient uniquement générées automatiquement (vous pouvez utiliser SET IDENTITY_INSERT pour insert des valeurs manuellement), ni garantir l'unicité entre les tables pour toute valeur.

Un GUID est pratiquement garanti pour être unique par système, donc si un guid est la key primaire pour les 4 tables, il garantit l'unicité pour toutes les tables. la seule exigence qu'il ne remplit pas est la taille de stockage – Sa taille de stockage est quadruple de celle de int (16 octets au lieu de 4).

Une SEQUENCE , lorsqu'elle n'est pas déclarée comme recykeye, garantit l'unicité et a la taille de stockage la plus faible.

La séquence de valeurs numériques est générée dans un ordre croissant ou décroissant à un intervalle défini et peut être configurée pour redémarrer (cycle) lorsqu'elle est épuisée.

Cependant , je choisirais probablement une option différente: créer une table de base avec une seule colonne d'identité et la lier avec une relation 1: 1 avec toutes les autres catégories. puis utilisez un triggersur à la place de insert pour toutes les tables de catégories qui insèrent d'abord un logging dans la table de base, puis utilisez scope_identity() pour get la valeur et insérez-la en tant que key primaire pour la table category. Cela renforcera l'unicité et rendra possible l'utilisation d'une reference de key étrangère unique entre les catégories et les produits.

La question a été largement discutée dans le passé, en général:

http://blog.codinghorror.com/primary-keys-ids-versus-guids/

La contrainte # 3 est la raison pour laquelle une SEQUENCE peut rencontrer des problèmes car il y a un plus grand risque de collision / un nombre réduit de lignes possibles dans chaque table.