Si. los autoincrementales son fáciles, y cuando te enseñan programación te los dan como si fueran algo natural. No es así.
Un ID autoincremental es una forma fácil de resolver las PK, pero sólo si trabajas con una única base, un sólo servidor y un mismo sistema completamente integrado.
Pero cuando tienes, por ejemplo:
- Varias bases que tengan tablas en común por su diseño, pero funcionen separadamente.
- Más de una "sucursal" con su propia base, la que debe consolidarse (concentrar los datos en una sola central cada tanto tiempo).
- Procesos de borrado y reinicio de bases por razones procedimentales o de seguridad.
- Datawarehouses o Datamarts.
- Procesos de integración de bases distintas con estructuras conceptuales coincidentes (clases o tablas).
- otros casos.En todas estas situaciones puedes encontrarte con solapamientos de claves (en la integración y recuperaciones de datos), o bien duplicaciones parciales de registros por claves no coincidentes (claves distintas con datos iguales).
Todo eso hace que cuando debas migrar o integrar tablas de diferentes orígenes, tengas que planear procesos que compensen esas discrepancias. Y todo proceso implica adicional ineficiencia y tiempo perdido.
Se supone, según los expertos en el tema de normalización de BBDD, que un indice numérico (autoincremental o no) sólo debe usarse si y sólo si llegados a la 3FN no has encontrado una clave candidata. Para el caso, existe una forma de evitar inconsistencias de integración entre diferentes bases y es haciendo que el
step (valor de incremento) de un AI sea mayor a 1, siendo normalmente equivalente a la cantidad de bases distribuidas que se usen (3 bases,
step de 3). En ese caso, al integrarlas, los registros quedan intercalados numéricamente sin conflictos. Pero tienen dos problemas: 1) No evita las duplicaciones de datos, solo los solapamientos, 2) no permite hacer listados directos sin verificar el valor de múltiplo de la PK.
Además de eso, una PK crea un índice cluster, el que se utiliza para mantener el orden físico de los registros, pero como es incremental , el orden es el de entrada, que puede no ser el orden más usado en las consultas, lo que obliga a crear indices específicos, que el sistema debe mantener actualizados según los datos que ingresen o se modifiquen. Si tienes en cuenta que muchas veces esos ordenes también implican hacer indices de tipo UNIQUE, el uso de la PK autoincremental deja de tener sentido, porque un indice de ese tipo implica que existe al menos una CC (clave candidata), y en ese caso ¿para qué usar una AI?
A nivel de consultas, debes tener en cuenta también que si la PK definida sobre los campos de la tabla contiene también los campos usados en la mayoría de las consultas, estas serán
siempre más eficientes que usar un AI. Incluso más: Aquellas consultas que impliquen sólo los campos que aparecen en el índice son mucho más rápidas, porque en ese caso MySQL lee el índice pero no lee la tabla.
El tema central es que una PK creada ortodoxamente en base a la definición del modelo relacional es
siempre la mejor de las opciones, por más complicaciones que te pueda traer en la programación. La ventaja que tienen para las migraciones es que como se definen sobre datos reales de la entidad representada, por más que haya repeticiones (manejables) en la integración, sabrás que no hay inconsistencias en los datos, y necesitarás procesos muchísimo más simples. A veces son simples
¿Se entiende por dónde va la cosa?