INT y AUTO_INCREMENT

[naitmeir]

Quiero poner un tipico campo identificador de tipo INT pero me surgen un par de questiones...

La primera es que pasara cuando se supera la capacidad del INT

La segunda es si el campo es del tipo AUTO_INCREMENT si se puede al borrar tuplas que este tipo de dato se incremente desde los campo que se han borrado...

Es decir... si tengo 1,2,3,4,5,6 y borro el 2 en vez de ser 7 el num siguiente al incrementarse tener algo como esto 1,3,4,5,6,2 y de ese modo incremetnar todos los campos que se fueran incrementando para completar espacios vacios...

[jvillamil]

Creo que si lees tu pregunta tu solo te puedes responder...

1. El campo que sea Int al momento de llegar al número "tope" no podrás insertar un nuevo registro en esa tabla, el motor de base de datos te debiera de mandar un error con lo ocurrido. Para resolverlo pon un tipo de datos "Bigint" y no esteres temeroso de cuándo pasara que llegue al tope

2. Para el incremental y usar el registro eliminado, pues no se puede a menos que tengas un trigger y lo estes desactivandi y activando el campo incremental y buscando un espacio vacio... pero yo no le veo sentido. Si el registro fue eliminado por algún motivo, debe quedar evidencia de que algo existió ahí y nadie mas ocupe ese lugar.

Espero haya servido de algo mi respuesta, salu2...

[gnzsoloyo]

Hace un tiempo se planteó este mismo problema, y sintéticamente lo que le comenté al forista era:

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 PK de un campo incremental no produce ninguna mejora en la optimización de consultas, por lo que resulta ineficiente y solamente resulta en tiempo de PC consumido.

3. Renumerar un campo autoincremental, reordenando la tabla sobre la base de otros campos, genera un nuevo ordenamiento FISICO de los datos, con la consiguiente sobrecarga del microprocesador, porque tiene que reescribir físicamente la tabla otra 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 puede 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 incremental? ¿para qué perder tiempo en renumerar?, ¿para que quede más lindo? .
En el caso de los rangos posibles de representación, un ID generado en un campo numérico UNSIGNED tiene estos rangos:
- TINYINT: 0 a 255.
- SMALLINT: 0 a 65.535.
- MEDIUMINT: a 16.777.215
- INT: 0 a 4.294.967.295.
- BIGINT: 0 a 18.446.744.073.709.551.615
¿Esperas usar más IDs que eso?

Yo creo que no te debes preocupar por el tema.