Trabajar con AUTO_INCREMENT

[occam25]

Hola,

Estoy mirando el AUTO_INCREMENT para que mysql vaya generando automáticamente un código de ingreso en una tabla. Hasta entonces lo hacía manualmente, mirando el código mayor e incrementando a partir de éste.

El AUTO_INCREMENT me funciona bien salvo que no se como hacer para que se actualice automáticamente.

Lo que quiero es que si, por ejemplo, tengo 5 registros y borro el 2 y el 3, que el índice se actualice y se reordene solo, quedando 1, 2, 3 en vez de como me queda ahora: 1, 4, 5

Además el índice a partir del cual sigue añadiendo tampoco se actualiza. Si tengo 5 registros y borro dos, al siguiente que añado le asigna un 6, no tiene en cuenta que he borrado dos y debería reordenar y asignar un 4.

Se puede hacer esto que digo o lo tengo que seguir haciendo yo manualmente?

Gracias y un saludo!

[gnzsoloyo]

Este es un tema recurrente, y en todos los casos muestra una falta de comprensión del sentido de un auto_increment, que en el caso de MySQL es ser clave primaria, lo que origina el problema principal, ya que por eso no se debe modificar un autoincrement en forma arbitraria.

Recordemos que :
a) Un campo AUTO_INCREMENT en MySQL es automáticamente definido como PRIMARY KEY.

b) Por definición, una PRIMARY KEY (PK) crea en forma automática un índice agrupado (cluster), que se utiliza para mantener el ordenamiento físico de los registros. Por esa razón también es único (un conjunto de datos no puede tener dos ordenamientos físicos diferentes en el disco, ¿o como ordenarías una biblioteca de dos formas al mismo tiempo?)

De tanto en tanto surge nuevamente este tema y en general lo que quieren hacer es siempre lo mismo: renumerar. El problema radica en que:

1. No es conveniente "reorganizar" un índice autoincremental porque en esencia es una tarea sin funcionalidad, carente de practicidad y consumidora innecesaria de tiempo de proceso.

2. El renumerar las PRIMARY KEY de un campo incremental no produce ninguna mejora en la optimización de consultas, por lo que hacerlo solamente resulta en tiempo de PC consumido.

3. Renumerar un campo autoincremental, genera un nuevo ordenamiento FISICO de los datos (una PK genera un índice cluster), con la consiguiente sobrecarga del microprocesador, porque tiene que reescribir físicamente la tabla cada vez y reconstruir el índice completamente.

4. Tampoco es recomendable bajo ninguna circunstancia renumerar una PK (es el caso en MySQL donde un AUTOINCREMENT es PK por default) si se usa como FK de otras tablas, porque generará inconsistencia de datos entre registros de tablas relacionadas.

5. No se recomienza renumerar si existen datos históricos de otras transacciones, que hacen referencia a otros registros que tenían el mismo número. De hecho, en una tabla de stock, las ID jamás cambian porque el hecho que un producto ya no exista ni se fabrique no quiere decir que no aparezca en registros más antiguos. Pisar un ID sería lo mismo que ponerle a un recién nacido el número de documento de un muerto.

6. Por otro lado, ¿qué te importa que tengas espacios de números que ya no usas, en tanto la numeración sea secuencial e incremental? ¿para qué perder tiempo en renumerar?, ¿para que quede más bonito? . Eso lo puedes hacer perfectamente en la interfase, donde visualizas la tabla de datos.

7. SI tu temor es quedarte sin números para usar, un ID generado en un campo numérico UNSIGNED tiene estos rangos:
[B]
- TINYINT: 0 a 255.
- SMALLINT: 0 a 65.535.
- MEDIUMINT: 0 a 16.777.215
- INT: 0 a 4.294.967.295.
- BIGINT: 0 a 18.446.744.073.709.551.615

Como sea, a mi entender es algo que no deberías preocuparte por hacer...

[occam25]

No es que quisiera renumerar por una razón estetica o algo parecido, solo para que el número no creciera demasiado (la cantidad de información crece bastante) y porq pensé que el auto_increment podría implementar algún procedimiento que lo hiciera automáticamente de manera sencilla, no pensé que consumiera tantos recursos el hacerlo.

Pero vale, me has convencido. Así se queda : )

Gracias por la aclaración

[gnzsoloyo]

Cualquier duda, ponle BIGINT UNSIGNED, que es el de más alta representación.,
Nunca dejes un auto_increment como SIGNED (valor por default, si no le indicas otra cosa), porque eso hará que pierdas la mitad del rango de representación, porque un auto_increment no puede generar valores negativos.
No te olvides...

[occam25]

Ok, así lo haré. Pero tarde o temprano desbordará, no? porque aunque haya un mantenimiento de la base de datos que borre los registros antigüos que ya no son necesarios, si el índice nunca se resetea llegará un momento en que llegue al máximo..

esperemos que tarde mucho y estar muy lejos cuando eso ocurra : P


gracias por la ayuda

[gnzsoloyo]

Mira, con más de dieciocho trillones de valores posibles para una PK con BIGINT, es poco probable que llegues al límite.
Piensa esto: Si tuvieses un millón de sucursales emitiendo una factura por segundo, tardarías 584.554 años, 6 meses y 18 díasen llegar a repetir el número de una factura.
¿Realmente crees que puedes preocuparte?

Por lo demás, si aún así quieres establecer un modo imposible de colisionar, deberás entonces establecer cuál es la clave candidata real, y no fabricar un ID autonumérico, esto es: identificar cuál es el campo o conjunto de campos que identifica unívocamente un registro en una tabla, para lo cual debes analizar y normalizar la tabla en cuestión.