Est-ce que RIDs uniques jamais « débordement »?

Question

Je fais une demande d'exécuter à la fois SQL Server et PostgreSQL, donc je pose cette question sur les deux.

Qu'est-ce qui se passe chaque fois que vous créez une clé primaire unique (en utilisant une séquence ou une chose de type auto-incrément) et vous touchez plus de 4 milliards d'enregistrements (32 bits)? Je ne dis pas que notre table aura 4 milliards d'enregistrements, mais plutôt que 4 milliards d'enregistrements ont été créés parce que les incréments RID seulement. Donc, même si je supprimé 3,9 milliards de ces documents, mes RIDs sont encore dans la gamme de 4 milliards. Alors qu'est-ce qui se passe? Est-ce la précision à 64 bits ou faut-il rouler sur 0 ou tout simplement cracher une erreur très critique? Dois-je craindre que même un 64 bits RID peut éventuellement déborder aussi?

En outre, comment puis-je me bats contre cela? Y at-il une sorte de nettoyage option ou outil? Est-ce que je viens de créer ma propre chose à chaque année ou reconstruire complètement la table pour obtenir RIDs cohérentes? (Et donc aussi toucher beaucoup d'autres tables qui utilisent ces RIDs sont les clés étrangères)

Answer 1

PostgreSQL, par défaut, l'erreur et non overflow:

# create sequence willyouwrap;
CREATE SEQUENCE
# select setval('willyouwrap', 9223372036854775807);
       setval        
---------------------
 9223372036854775807
(1 row)
# select nextval('willyouwrap');
ERROR:  nextval: reached maximum value of sequence "willyouwrap" (9223372036854775807)

A partir de la documentation:

  

Les séquences sont basés sur l'arithmétique bigint, de sorte que l'intervalle ne peut pas dépasser l'amplitude d'un nombre entier de huit octets (-9223372036854775808 à 9223372036854775807). Sur certaines plateformes plus âgés, il pourrait y avoir aucun support du compilateur pour les entiers huit octets, dans lequel les séquences de cas utilisent une arithmétique entière ordinaire (plage -2147483648 à 2147483647).

Cependant, vous pouvez le faire du cycle:

  

L'option CYCLE permet à la séquence d'enveloppement lorsque valeurmax ou minvalue a été atteint par une séquence ascendante ou descendante, respectivement. Si la limite est atteinte, le prochain numéro sera généré valeurmin ou maxvalue, respectivement.

     

Si NO CYCLE est spécifié, tout appel à nextval après la séquence a atteint sa valeur maximale renverra une erreur. Si aucun CYCLE ou NO CYCLE sont spécifiés, NO CYCLE est la valeur par défaut.

Ne pas combattre. Passez les octets supplémentaires et de garder les choses simples. Vous êtes plus susceptible de regretter d'ajouter des couches supplémentaires de complexité et / ou d'entretien que d'avoir une plus grande keyspace.

Answer 2

Sur SQL Server: Cela dépend du type de la colonne RID. L'identité interne peut augmenter, mais ne parviendra pas à attribuer à la colonne stoarge:

CREATE TABLE [t1] (
[tid] int IDENTITY (2147483647, 1) NOT NULL
  , name varchar(1)
) ON [PRIMARY]
GO
insert into t1(name) values('1')
insert into t1(name) values('1')

ce qui déclenche l'erreur:

Msg 8115, Level 16, State 1, Line 2
Arithmetic overflow error converting IDENTITY to data type int.
Arithmetic overflow occurred.

Mais une colonne numérique avec suffisamment de stockage incrémente très bien:

CREATE TABLE [t1] (
[tid] numeric(38,0) IDENTITY (2147483647, 1) NOT NULL
  , name varchar(1)
) ON [PRIMARY]
GO
insert into t1(name) values('1')
insert into t1(name) values('1')

De même, un bigint sera overlfow à 2 ^^ 63-1:

CREATE TABLE [t1] (
[tid] bigint IDENTITY (9223372036854775807, 1) NOT NULL
  , name varchar(1)
) ON [PRIMARY]
GO
insert into t1(name) values('1')
insert into t1(name) values('1')

mais une colonne numérique avec stockage suffisante réussira:

CREATE TABLE [t1] (
[tid] numeric(38,0) IDENTITY (9223372036854775807, 1) NOT NULL
  , name varchar(1)
) ON [PRIMARY]
GO
insert into t1(name) values('1')
insert into t1(name) values('1')