Que se passe-t-il lorsque le moteur de base de données n'a plus de chiffres à utiliser pour les clés primaires?

Question

Depuis Les bases de données ne réutilisent pas les numéros d'enregistrements supprimés . Il est donc possible de manquer de chiffres, surtout si vous ne choisissez pas vraiment un type entier grand pour cette colonne.
Que se passerait-il et comment l'éviter si c'était mauvais?

// SQL Server, MySQL //

Answer 1

Je pense exactement que ce qui se passera dépendra du moteur de base de données que vous utilisez (il peut même y avoir des différences entre INNODB et MyISAM dans MySQL). Quoi qu'il arrive, ça ne va pas être joli.

Vous devez simplement changer le type de colonne en un entier plus grand.

Answer 2

Vous vous retrouvez avec un temps d'arrêt de plus de 3 heures, comme Slashdot . a fait sur sa fonction de commentaires.

Answer 3

Pour MySQL, il est documenté que :

  

Le comportement du mécanisme d'auto-incrémentation n'est pas défini si un utilisateur attribue une valeur négative à la colonne ou si la valeur devient supérieure à l'entier maximal pouvant être stocké dans le type entier spécifié.

Answer 4

La plupart des systèmes de base de données ont un type de données numérique pouvant avoir une largeur supérieure à 32 bits. Si vous prévoyez plus de 2 ^ 32 enregistrements, vous devez utiliser une largeur de clé appropriée.

Answer 5

Oui, c'est possible: si vous n'autorisez que des numéros à 2 chiffres, vous ne pouvez avoir que des ID allant jusqu'à 99, et ainsi de suite. Les insertions échoueraient une fois la limite atteinte. Il est de bon sens de choisir une taille appropriée.

Answer 6

Dans Postgres, le "serial" type équivaut à la création d'une SEQUENCE avec l'option NO CYCLE et à la définition de la valeur par défaut du champ sur nextval. L’épuisement d’une telle séquence génère une erreur:

http://www.postgresql.org/docs/8.3 /interactive/sql-createsequence.html

Answer 7

Cela dépend de votre base de données. Je crois que dans MS SqlServer, vous ne pouvez simplement pas insérer de nouvelles lignes tant que vous n'avez pas résolu le problème. La dernière fois que je l’ai rencontré, nous avons résolu le problème en réaménageant la colonne identité à 1. Ce n’est évidemment pas un correctif universel, mais notre situation était satisfaisante.

Answer 8

Oracle ne prend pas en charge les colonnes d’auto-incrémentation et la pratique habituelle consiste à utiliser un générateur de séquence. Une séquence génère des entiers pouvant aller jusqu'à 28 chiffres, donc si vous en manquez, alors ... Je suppose que vous avez une assez grande table. Mais le comportement dépend alors de la configuration du générateur de séquence: une erreur ou un retour à la valeur de départ et une violation de contrainte PK lors de l’insertion suivante.

Answer 9

J'ai essayé cela dans SQL 2000 il y a quelque temps. Après Integer.MaxValue, la valeur d'identité suivante est Integer.MinValue. Il continue ensuite à compter comme vous vous en doutez. Tant que les disques qui existaient auparavant à 1,2,3, etc. ont disparu, il ne se passera rien de mal. S'il se trouve en double (et que le champ est la clé primaire), l'insertion échoue avec une violation de clé. Cependant, je n'ai pas essayé de colonne d'identité qui ne soit pas contrainte à des valeurs uniques. Je suppose qu’il serait content des doublons.

Answer 10

Généralement, vous obtiendrez une erreur. Utilisez un BIGINT si vous êtes paranoïaque.