¿Qué hacer cuando un campo en una tabla se aproxima al entero máximo de 32 bits con signo o sin signo?

14

En cualquier base de datos que contenga registros de usuario en forma de un campo de incremento automático único (por el ejemplo, mensajes entre usuarios) ... qué hacer cuando llegue el momento y se acerque al número máximo con o sin signo del tipo de datos actual? (Un INT de 32 bits)? Supongo que el servidor de la base de datos se desbordará cuando intente asignar el número (2∧32) -1 a la siguiente entrada, entonces, cómo evitar que eso suceda (sin cambiar el tipo de datos, por el bien de la pregunta) y seguir agregando registros? ¿Qué harías?

¿Por qué usaría INT y no, por ejemplo, VARCHARS?

Han pasado varios días desde que me hice esta pregunta hipotética y me gustaría saber qué haría un profesional.

mysql

— AeroCross
fuente

12

Por lo general, usaría números enteros en lugar de varchars porque consumen menos espacio, han entendido bien que los patrones de clasificación son rápidos de indexar, etc. Los enteros son tipos de datos naturales de una CPU y, por lo tanto, el rendimiento es generalmente óptimo. Normalmente, un número entero es de 4 bytes, equivalente a solo 4 caracteres en un varchar (no unicode).

Si le preocupaba quedarse sin espacio con un tipo INT, intente con BIGINT, que le proporciona números de 8 bytes. El límite de esto es bastante grande, y probablemente se quedará sin espacio en disco antes de alcanzar ese límite de registros :-) El rendimiento de BIGINT también será muy bueno, especialmente porque muchos servidores ahora también tienen 64 bits. .

La respuesta a la primera parte de su pregunta sobre lo que sucede cuando se queda sin INTs no es simple, especialmente como dijo sin cambiar el tipo de datos a BIGINT. Básicamente, no hay mucho que pueda hacer, y lo que puede hacer está muy limitado por la naturaleza de los datos en su base de datos. ¿Qué registros tienen claves externas para estos datos? ¿Todavía necesita todos los datos en esa tabla y los registros relacionados? Suponiendo que podría archivar una gran cantidad de datos iniciales (y sus datos relacionados), entonces lo único que puedo sugerir es mover los datos fuera de la tabla (digamos los primeros 1 a X millones de registros), y luego restablecer el origen de identidad a 1. Hay todo tipo de razones, aunque no lo recomendaría, por ejemplo, hay muchos bits de código que he visto que hacen cosas como verificar el valor máximo de un campo de identificación, para ver lo que se acaba de agregar, y eso no funcionaría (y no debería hacerse). Además, las personas suponen que el registro N se creó antes de N + 1. No hay una respuesta fácil, creo.

Finalmente, no sé acerca de MySQL, pero SQL Server daría un error de desbordamiento si alcanza el límite.

— Miles D
fuente

1

Estoy satisfecho con una respuesta tan detallada. Gracias por la explicación del acuerdo VARCHAR, INT y BIGINT. Como la pregunta es hipotética, me pregunto qué pasaría si también se alcanza el límite BIGINT. La pregunta fue planteada por una publicación que vi sobre Facebook usando INT y llegando al límite, y lo veo como totalmente posible. El archivado funcionaría, o crear una segunda tabla con una declaración condicional (que, como dijiste, también requeriría la actualización de los scripts, y sería bastante complejo). En general, excelente respuesta. Agradezco el tiempo empleado.

— AeroCross

9

Un punto que se pasa por alto es que muchas personas comienzan el número automático o la identidad en 1, por lo que pierden la mitad del rango posible de inmediato (para firmar)

Simplemente redefiniría el número para comenzar en -1, incrementar -1 en este caso.

Podría decirse que si alguna vez esperaba llenar su columna de identidad, entonces debería haber diseñado esto y utilizado un tipo de datos más amplio al principio.

Vea esta pregunta reciente sobre SO: SQL Server 2008: ¿qué sucede si la identidad sobrepasa un valor máximo de int?

— gbn
fuente

Es lógico que use un tipo de datos más amplio (para una tabla que indique cómo ESA cantidad de datos), pero como era una pregunta hipotética, quería una idea. Si está firmado, eso puede funcionar (pero sería un poco extraño tener una clave principal con números negativos, en mi humilde opinión) y creo que es bastante inteligente. Le daría tiempo al DBA para archivar los datos positivos y comenzar de nuevo. Si no está firmado, bueno ... problemas.

— AeroCross

Alternativamente a usar un incremento de -1 desde -1, comience en (-2147483648) e incremente en 1. Pero sí, después de cruzar INT_MAX, entonces está bastante bien y necesita volver a visitar el diseño, y eliminar el índice anterior reemplazándolo. con uno nuevo más grande. y si pasa BIGINT sin firmar, entonces quiero venir a trabajar en su equipo;)

— jcolebrand

PostgreSQL usa secuencias para generar números de identificación; la instrucción CREATE SEQUENCE le permite especificar CYCLE, que simplemente se ajustará si alcanza el valor máximo. (O el valor mínimo, si va en la otra dirección). La opción CYCLE está en los estándares SQL ahora. (Desde al menos 2003.)

— Mike Sherrill 'Cat Recall'

4

¿Desbordamiento BIGINT? Jaja. Primero descubre cómo lograr la inmortalidad. INT SIN FIRMAR (4 mil millones) es lo suficientemente difícil de alcanzar. 100 INSERTOS por segundo estarían cerca de desbordar INT en un año. BIGINT llevaría varios miles de millones de años.

Para corregir: ALTER TABLE foo MODIFY COLUMN id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT; Pero eso llevará horas porque copiará sobre la tabla (que tiene cerca de 4 mil millones de filas, ¿verdad?) Y reconstruirá todos los índices secundarios. Plan Ahea d.

En general, cuando intenta almacenar un número demasiado grande para un campo (por ejemplo, 999 en un TINYINT SIN FIRMAR), lo silenciará al máximo para el campo (255 en este caso). Puede haber una "Advertencia", pero la mayoría de las personas no se molestan en verificar las advertencias. Si es un campo ÚNICO, o hay CLAVES EXTRANJERAS, es posible que obtenga un error más grave.

CHAR o VARCHAR se trunca silenciosamente en el espacio disponible.

— Rick James
fuente