Disculpa, pero eso es razonamiento de programador... No debes razonar los problemas del modelo de datos como resuelves los asuntos de programación, porque los principios son distintos.
Primero: Una clave no es simplemente un índice numérico al azar. Es un identificador de objetos únicos, por lo que cambiar el ordenamiento o numeración de los objetos contenidos en la tabla tiene muchas más implicancias que solamente los números ordenados de la lista.
En ese sentido, tienes que considerar también que una clave primaria se usa para ordenamientos físicos de los registros, por lo que alterar su numeración implica también reordenar los registros en disco. Todos. ¿Tiene sentido esa tarea simplemente para que quede numéricamente
bonito?
A esto tienes que sumarle que si esa clave (especialmente las primarias) se usa para establecer las relaciones entre tablas, no sólo tienes que cambiar la numeración en la tabla origen. Tendrás que hacerlo en
todas las tablas donde se use ese valor de referencia. O sea, tiempo de proceso inútil y riesgo de errores de integridad.
Segundo: La idea, que puede parecer buena a nivel prorgamación, es una enorme pérdida de tiempo cuando trabajas en BBDD. De hecho, la misma existencia de ese campo "UID" simplemente para mantener una numeración consecutiva y solventar los "saltos" del autoincremental, es innecesaria, porque si lo que quieres es usar un número secuencial para mostrar en pantalla... no lo necesitas. Hay otras formas mucho más eficientes para eso. Incluso las puedes encontrar en las FAQs de este subforo.
Finalmente, si aún así insistes en hacer esto, tienes tres opciones: 1) Hacerlo programáticamente. 2) Hacerlo en una consulta UPDATE global donde el parámetro del WHERE sea igual o mayor al UID eliminado. 3) Usar un TRIGGER, con lo que sólo recargarás a la base con tareas que en el fondo no se necesitan.
Ninguna de las dos primeras es práctica si la tabla tiene muchos registros, por cuanto no sólo llevará mucho tiempo, sino que además generará bloqueos a los usuarios concurrentes. Y eso es una muy mala practica.
Siempre es preferible sacrificar las cosas "bonitas" en aras de la eficiencia de la base, y ese no es el caso que estás buscando. Tarde o temprano lo pagarás con performance.
Yo en realidad no usaría ninguna. Eliminaría ese campo inútil (yo ya experimenté el mismo caso, y finalmente careció de utilidad y practicidad) y usaría una solución dinámica que, como dije, puedes encontrar
en las FAQs de MySQL.
