¿Hay alguna razón para no usar auto_increment en un índice para una tabla de base de datos?

Question

Heredé la tarea de mantener un sitio de comercio electrónico muy mal codificado y estoy trabajando en la refacturación de una gran cantidad del código y tratando de solucionar los errores actuales.

Cada inserción de base de datos (agregar un artículo al carrito, etc.) comienza con una función grab_new_id que CUENTA el número de filas en la tabla, luego, comenzando con ese número, solicita la base de datos para encontrar un número de índice sin usar. Además de ser terrible en cuanto a rendimiento (hay más de 40,000 filas y los índices se eliminan regularmente, por lo que a veces lleva varios segundos encontrar una nueva identificación) esto se rompe regularmente cuando se realizan dos operaciones simultáneamente, ya que se agregan dos entradas. con números de identificación duplicados.

Esto parece idiota a mí - ¿por qué no usar incremento automático en el campo de índice? Lo probé de ambas formas, y agregar filas a la tabla sin especificar un ID de índice es (obviamente) mucho más rápido. Mi pregunta es: ¿alguien puede pensar en alguna razón por la que el programador original pudo haber hecho esto? ¿Hay alguna escuela de pensamiento en la que el autoincremento se considere de alguna forma mala? ¿Hay bases de datos que no tienen capacidades de auto incremento?

Answer 1

que he visto esto antes de alguien que no sabía que existían función. Definitivamente use la función de incremento automático.

Algunas personas toman el "hágalo usted mismo" enfoque de todo, a menudo porque no se han tomado el tiempo para ver si esto es una característica disponible o si alguien ya había llegado con él. A menudo verá soluciones locas o código deficiente/frágil de estas personas. Heredar una mala base de datos no es nada divertido, ¡buena suerte!

Answer 2

Bueno Oracle tiene secuencias, pero no los identificadores generados automáticamente como yo lo entiendo. Sin embargo, generalmente este tipo de cosas las realizan los desarrolladores que no entienden la programación de bases de datos y que odian ver brechas en los datos (a medida que se obtienen los retrocesos). También hay personas a las que les gusta crear el ID, por lo que lo tienen disponible para usarlo en las tablas secundarias, pero la mayoría de las bases de datos con identificadores autogenerados también tienen una forma de devolver ese ID al usuario en el momento de la creación.

Answer 3

Pueden apenas han sido inexperto y no están familiarizados con incremento automático. Una razón por la que puedo pensar, pero que no tiene mucho sentido, es que es difícil (no imposible) copiar datos de un entorno a otro cuando se usan identificadores de incremento automático.

Por esta razón, he utilizado Guiales secuenciales como mi clave principal antes para facilitar la transición de datos, pero contar las filas para llenar el ID es un poco WTF.

Answer 4

Pude ver si los identificadores se generaron en el cliente y se introdujeron en la base de datos, esta es una práctica común cuando la velocidad es necesaria, pero lo que se describe parece excesivo e innecesario. Quítelo e inicie una identificación con incremento automático.

Answer 5

Probablemente fue así por razones históricas; es decir, las versiones anteriores no tenían variables autoinc. He escrito un código que usa campos automáticos manuales en bases de datos que no admiten tipos autoinc, pero mi código no era tan ineficiente como sacar un conteo().

Un problema con el uso de campos AutoInc como clave principal es que los registros de entrada y salida de las tablas en movimiento puede provocar un cambio en la clave principal. Por lo tanto, recomendaría diseñar en un campo "LegacyID" desde el principio que pueda usarse como almacenamiento futuro para la clave principal en los momentos en que mueve registros dentro y fuera de la tabla.

Answer 6

El único problema que encontré fue parcialmente razonable (¡pero totalmente evitable!) contra los campos auto_inc es que algunas herramientas de copia de seguridad por defecto incluyen valores auto_inc en la definición de la tabla, incluso si no incluye datos en un volcado de db que pueden ser inconvenientes.

Answer 7

Dependiendo de la situación específica, existen claramente muchas razones para no usar números consecutivos como clave principal.

Sin embargo, en virtud de lo dado que hago quieren números consecutivos como clave principal, no veo ninguna razón para no utilizar el construido en auto_increment funcionalidad de MySQL ofrece

Answer 8

Dos cosas a tener en cuenta:

1. Su RDBMS establece de manera inteligente el valor de autoincrecimiento al reiniciar. Nuestros ingenieros estaban lanzando su propia clave de incremento automático para moverse por el campo de incremento automático saltando en un orden de 100000 cada vez que se reiniciaba el servidor. Sin embargo, en algún momento Sybase agregó una opción para establecer el tamaño del incremento automático.

2. El otro lugar donde el auto-incremento puede ser desagradable es si está replicando bases de datos y está usando una configuración maestra-maestra. Si escribe en ambas bases de datos (NO SE ACONSEJA), puede encontrarse con una colisión de identidad.

Dudo cualquiera de estos fueron el caso, pero hay que tener en cuenta.