Volver a sembrar la columna de identidad: cuando es necesario?

Durante una de las últimas lecciones en la universidad (soy estudiante), el profesor nos pidió que desarrollemos una base de datos (MySQL Server si es importante) y una pequeña aplicación cliente que consumiría la base de datos como fuente de datos.

Uno de los requisitos era que la columna de identidad (que es el PK en cada tabla) debe ser secuencial, porque es una buena práctica (según las palabras del profesor). Es decir, cuando se elimina la fila de la tabla, su PK debe reutilizarse en inserciones posteriores. Tengo un conocimiento promedio en RDBMS, PK y columnas de identidad. Por lo que entiendo, esa columna de identidad es solo una forma de permitir que DB genere PK automáticamente al insertar filas y nada más. Y el valor de la columna de identidad no debe estar relacionado con los atributos de fila de ninguna manera (siempre que no sea una clave natural).

Este requisito (columna de identidad estrictamente secuencial) me resultó sospechoso. Intenté preguntarle al profesor qué está mal si la identidad no es secuencial (con huecos causados ​​por eliminaciones), pero obtuve una respuesta muy abstracta como "es conveniente para los usuarios y útil para los administradores de bases de datos que mantienen la base de datos". No hay ejemplos específicos. El argumento "conveniente para los usuarios" suena tonto, porque no tiene ningún significado en el dominio empresarial.

Por lo tanto, tengo curiosidad si estas razones son reales? Solo puedo pensar en un caso en el que se requiere la reinicialización de la columna de identidad, cuando se agota el espacio de identidad. Pero esto es más un problema de diseño cuando el tipo de columna de identidad se eligió incorrectamente, digamos simple en intlugar de biginto uniqueidentifiercuando la tabla contiene mil millones de filas. Supongamos que una columna de identidad es un índice agrupado: ¿pueden las brechas en la columna de identidad afectar el rendimiento del índice? ¿Quizás hay otras razones del mundo real para la reinicialización automática de la columna de identidad después de cada eliminación que desconozco?

¡Gracias por adelantado!

Es decir, cuando se elimina la fila de la tabla, su PK debe reutilizarse en inserciones posteriores.

¿De qué universo es tu profesor?

Eso es extremadamente ineficiente. Si intenta hacer eso, reducirá sus perspectivas de rendimiento en un factor de 10.

Si necesita números sin espacios por motivos de auditoría, compílelos explícitamente, no directamente desde las herramientas de la base de datos. Y nunca elimine filas, sino que las marque como "eliminadas". Esto se sumará al desorden de las consultas, ya que tendrán que ignorar dichas filas.

En MySQL, InnoDB requiere la existencia de un único PRIMARY KEYpara cada tabla. Pero ese es el alcance del requisito. La clave incluso puede ser una cadena.

Las brechas son una conveniencia para los usuarios y los DBA, no un inconveniente.

Puedo pensar en un caso en el que sin espacios sería conveniente: agruparse en grupos de 100 filas a la vez. Pero hay una solución simple usando LIMIT 100,1.

Las brechas tienen cero impacto en el rendimiento. Eso incluye índices no numéricos. E índices no únicos. E índices compuestos.

Claro, puedes quedarte sin identificadores. Creo que lo he visto suceder dos veces en casi 2 décadas de uso de MySQL. También podría preocuparme de ser golpeado por un asteroide. Está bajo en mi lista de cosas que me mantienen despierto por la noche.

Las lagunas se producen a partir de (al menos): INSERT IGNORE, IODKU, REPLACE, DELETE, ROLLBACK(explícita o debido a la caída), la replicación multi-master (incluyendo Galera y grupo de replicaciones). ¿De verdad quieres encontrar soluciones para esos?

Siéntase libre de hacernos revisar la cordura, verifique cualquier otra cosa que el profesor diga que es sospechosa.

La reutilización de un valor de identidad, en general, debe desalentarse. O bien, el valor se usa completamente internamente, en cuyo caso su valor real es irrelevante, o también se usa externamente, en cuyo caso la reutilización del valor probablemente conducirá a una identificación errónea.

Tome el caso obvio de una factura o un número de orden de compra, estos pueden provenir fácilmente de una columna de identidad y estar expuestos externamente, pero nunca querrá reutilizarlos precisamente por esa razón. Ambos se refieren a transacciones específicas que no querrá confundir.

Resolver estos problemas puede ser una gran molestia cuando las empresas se fusionan o se adquieren. ¿Crear tales problemas a propósito? No sabio.

La reutilización de los valores de ID de PK tiene problemas y, por lo general, debe evitarse.

Primero, la implementación de columnas auto_increment no proporciona la garantía de ser sin espacios. De hecho, se producirán huecos si revierte una inserción en una columna de incremento automático.

En segundo lugar, la ID de la brecha puede referirse a datos existentes que no se han eliminado (debido a la falta de restricciones FK). Si se traducen en números de miembros comunicados fuera del sistema, eso plantea riesgos potenciales de identidad comercial.

En tercer lugar, bigint unsignedno se quedarán sin ID durante un tiempo significativo, incluso dada una tasa de inserción extremadamente grande.

El mayor dolor con las brechas se encuentra con los auditores que insisten en que es una falla de auditoría. Para los DBA saben que existen brechas y por qué.

No haré eco de los comentarios de todos los demás de que reutilizar un PK es una mala idea, pero me he encontrado con momentos en los que era necesario volver a sembrar una columna de identidad.

La corrupción del índice PK en sí.

De acuerdo, esto estaba usando MS-SQL y hace muchos, muchos años, pero aún es relevante. Hace muchos años, para la compañía para la que trabajo, alguien pensó que sería una buena idea reutilizar las PC como servidores en nuestras más de 150 ubicaciones remotas después de que eran demasiado viejas para ser utilizadas por los clientes y luego guardarlas en un armario Sin ventilación. Cuando no, porque todos sabemos que un montón de computadoras basura de 10 años en una habitación pequeña con temperaturas de más de 120 bases de datos de misión crítica solo podrían resultar en cosas buenas. Como un 40% de tasas de fracaso y yo repensando mi elección de carrera Volveríamos a replicar los datos en la sede de la corporación, pero la mayoría de las veces, estas fallas darían lugar a cosas malas que suceden a las bases de datos. Una de esas cosas era que la base de datos tenía índices corruptos que incautarían la base de datos y el proceso de replicación. Dos veces en este gran entorno, la única solución para corregir la replicación era reiniciar los índices y luego restablecer la replicación. Reemplazamos los servidores más tarde antes de abandonarlos por completo.