La réutilisation de l'identité de la valeur après la suppression de lignes

Est-il possible de réutiliser une identité, d'une valeur de champ après la suppression de lignes dans SQL Server 2008 Express? Ici est un exemple. Supposons que j'ai une table avec un champ Id comme clé primaire (de l'identité). Si j'ajoute cinq lignes, je vais avoir ces 5 Id: 1, 2, 3, 4, 5. Si je devais supprimer ces lignes, puis ajouter cinq de plus, les nouvelles lignes aurait Id: 6, 7, 8, 9, 10. Est-il possible de le laisser recommencer à nouveau en 1?

Dois-je supprimer les données d'une autre table afin d'accomplir cette? Merci pour votre aide.

Entendez-vous l'identité de champ? La clé primaire pour presque toutes mes tables est ID et qui est généralement (mais pas exclusivement) un champ d'identité
Oui, je voulais dire un champ d'identité.
Juste parce qu'il y est une manière de le faire ne signifie pas que vous devriez.

OriginalL'auteur Jeremy | 2010-11-26

  1. 21

    Vous pouvez utiliser la syntaxe suivante pour définir la valeur d'IDENTITÉ:

    DBCC CHECKIDENT (orders, RESEED, 999)

    Cela signifie que vous aurez à exécuter l'instruction basée sur tous les SUPPRIMER. Cela devrait commencer à mettre en évidence pourquoi c'est une mauvaise idée...

    La base de données ne se soucie pas des valeurs séquentielles - c'est pour fins de présentation seulement.

    Si vous souhaitez insérer une ligne avec l'ID 10, vous devez réamorcer avec ID 9. En supposant que l'incrément est 1.
    Vous pouvez aussi l'utiliser dans le but de trouver votre graine de valeur: sélectionnez ident_current ("table_name") comme current_identity

    OriginalL'auteur OMG Ponies

  2. 9

    Si vous souhaitez réinitialiser l'identité, après la suppression de tous rangs puis effectuez l'une de ces

    --instead of delete, resets identity value
TRUNCATE TABLE orders

--or if TRUNCATE fails because of FKs, use this after DELETE
DBCC CHECKIDENT (orders, RESEED, 1)

    Sinon, la valeur interne ne devrait pas question de savoir si des lacunes ou pas.

    OriginalL'auteur gbn

  3. 6

    identity champs ne pas réutiliser les anciennes valeurs par défaut. Vous pouvez réensemencer avec dbcc checkident, mais ce n'est pas suggéré que vous obtiendrez des violations de clé si vous réamorçage en dessous d'une valeur qui existe encore dans le tableau. En général, vous ne devriez pas vous soucier de ce que les valeurs de clé primaire. Le fait qu'ils ne sont pas contigus ne fait pas de mal quoi que ce soit.

    Le fait qu'ils ne sont pas continues en fait quelque chose de mal, parce que supprimé les valeurs ne sont pas réutilisées. Depuis un 32-bit de la colonne d'identité serait limitée à un maximum de 2^32 (ou 2^31 si l'exclusion des valeurs négatives) les insertions et les suppressions, après qui insère serait la cause d'une erreur de dépassement de capacité. C'est essentiellement une sorte de fuite de ressources. J'ai fait quelques calculs et a déterminé qu'une 32-bit de la colonne d'identité n'est pas l'avenir, et même une version 64-bit de la colonne peut-être pas assez, depuis un ordinateur seulement 1000 fois plus rapide que mon bureau pourrait manger des valeurs dans moins d'un an. Afin de 128 bits Guid FTW.
    À l'aide d'un bigint la colonne d'identité vous permet de vous 2^63 - 1 lignes. C'est 9 quintillion lignes. Même à un billion de dollars insère par jour, cela va encore durer 25 000 ans.

    OriginalL'auteur Donnie