cambiar los id (auto_increment)

[gnzsoloyo]

El tema de si mis modos son o no como dices es algo que podemos tratar por MP. No voy a decir nada acá porque nos desviaría del asunto de tu pregunta. Sólo diré que rara vez he tenido algún conflicto por alguna frase y normalmente ha sido un malentendido.

El asunto de renumerar los autoincrementales es un tema recurrente en este foro, por eso te puse el link. Lo otro fue una reflexión. Cada tanto alguien consulta por lo mismo, y siempre es en definitiva dentro del mismo contexto de problemas. Normalmente siempre le aconsejamos lo mismo: No es necesario, no aporta nada, no es conveniente por varias razones, etc.. Por eso ese post está entre las FAQs de MySQL.

En definitiva:
- ¿Es conveniente hacerlo?
En la inmensa mayoría de los casos NO. En muy contadas y raras ocasiones puede aportar algo al modelo de datos. Pero por lo general el problema se origina a causa de que los AI son sencillos de entender para los programadores, y los usan indiscriminadamente sin tener idea de los problemas que causan a futuro, tanto en el mantenimiento como en las migraciones. Es algo de fiaca de programar, como se suele decir entre los de Bases de Datos.
Como son fáciles de programar, se suele creer que son lo mejor y no es así. En mi práctica no he encontrado casos en donde no pueda resolver el problema directamente suprimiendo los AI y poniendo una PK más ortodoxa, que no dependa de ellos.

- ¿Trae alguna ventaja?
Renumerar no produce realmente ninguna ventaja a la base de datos o a las aplicaciones. Si no es por una cuestión estética, en la mayoría de las ocasiones, la renumeración sólo se traduce en tiempo de procesamiento consumido.

- ¿Trae desventajas?
Causa serios problemas de migración cuando trabajas con tablas que no sean InnoDB, o en tablas InnODB donde las FK no hayan sido creadas con la opción ON UPDATE CASCADE. En esos casos la migración de datos debe crearse manualmente, con todo lo que conlleva.
Además, si hay datawarehosues, bases de respaldo, paralelas o backups históricos, generan inconsistencia de datos que no se puede resolver fácilmente.

- ¿Hay buenos motivos para hacerlo?
Personalmente no veo que las razones que expones sean técnicas, sería interesante saber qué es lo que hace que una numeración consecutiva sea "amigable" como comentas, o cómo se facilita el trabajo. Si las ven "mejores", no parece ser por cuestiones ni de performance, ni necesidades del sistema, ni tampoco parecen surgir de las reglas del negocio o del relevamientos del sistema mismo. Y si no entra en ninguna de esas categorías...
Por otro lado, ten en cuenta primero que no necesitas obligatoriamente una PK autonumerica, sino una PK elegida según el modelo E-R. Eso realmente te produciría ventajas en varios niveles. Además, se trata de una solución absolutamente transitoria, porque si esos registros se pueden borrar por necesidades del sistema, eventualmente tendrás el mismo problema de "huecos" dentro de un tiempo. ¿Volverás entonces a "renumerar"?

En definitiva, si aún así quieres hacerlo, para eso tienes que modificar la tabla (ALTER TABLE... AUTO_INCREMENT = 1;), porque el AI está en la definición de la misma.
El problema es que si la tabla ya tiene datos, no podrás hacerlo sin hacer una migración porque la renumeración desde 1 hará que en un momento dado se genere un conflicto de clave duplicada.

Otra posibilidad es medio brutal: Borrar el campo y volverlo a definir. Esto es efectivo si y sólo si no hay tablas dependientes de la tabla modificada.
Si hay al menos una, no podrás hacerlo.
Y aún cuando puedas hacerlo, siempre tendrás que asegurarte que la información resultante en la base queda efectivamente consistente. No te olvides que mientras mayor es la complejidad de las relaciones, más probable es que no puedas modificar una PK sin armar un gran problema...

Una tercera situación es si estás en etapa de desarrollo y estás usando datos de prueba. En ese caso lo más simple es usar TRUNCATE en las tablas InnoDB. Eso elimina los datos y reinicia el DI. Pero con tablas MyISAM deberás aún así usar ALTER TABLE porque TRUNCATE no tiene efecto sobre el valor de AI.

Mi sugerencia final es simple: Trata de no usar PK que sean AI. No son obligatorias en el modelo relacional, ya que lo que define una PK no es eso, y traen problemas en las migraciones. Usar una PK mejor elegida es mucho mejor que usar un AI.