Cita: frameworks como symfony utilizan por defecto este sistema de ingteractuar entre tablas.
Por empezar, cuando hablamos de Bases de DAtos, olvídate de los frameworks. No existen para las bases de datos, es programación, y lo que hacen los fmwk no abarca la las decisiones de diseño que se tomen.
Incluso se puede decir que muchas veces son contraproducentes para la performance, porque aplican un concepto no necesariamente eficiente del uso de las bases de datos.
El tema en si, es largo, algo complejo y en ciertos aspectos requiere de conocimientos conceptuales que rara vez puedes aprender en los tutoriales.
Tratando de simplificar, hay razones a favor y en contra de ambas posturas, pero el lo concreto es que termina siendo una decisión de diseño, ya que no hay reglas absolutas.
Mirados desde la óptica del modelo E-R, usar autoincrementales como ID, es un defecto, ya que lo que se postula es que una instancia de una entidad tiene por definición de su propia identidad, una clave natural, que surge de los propios atributos. Es decir, siempre existe un atributo o grupo de ellos que puede identificar unívocamente a esa instancia en todo el universo de instancias posibles.
El proceso de normalización de bases de datos sugiere que los ID numéricos se usen sólo si llegados a la 3FN no se ha encontrado una CC. Más allá de eso, no es muy convniente.
Los identificadores naturales tienen algunas ventajas:
- Son realmente únicos, lo que permite que diferentes bases con la misma entidad jamás se pisen identificadores, ya que siempre se referirán a la misma instancia (aunque los atribuitos no claves no sean los mismos).
- Las consultas principales siempre usan como parámetros precisamente aquellos atributos que son clave.
- Cuando los parámetros forman parte de las busquedas, los indices primarios definidos son un excelente recurso. Y cuando sólo se consulta por ellos, entonces se leen índices y no tablas (mejor performance).
- El uso de claves naturales permite integración de bases, migraciones y consolidaciones sin conflictos.
Como "contra", implica que requieren mejores análisis de estructura de datos, normalizaciones mas detalladas y una fuerte vigilancia respecto a la consistencia de datos en las estructuras.
En otras palabras, exigen
trabajar, y mucho.
También pueden ocupar más espacio de disco, pero actualmente esto es de peso relativo (tenía más impacto cuando la relación almacenamiento/costo era mayor).
Las claves autoincrementales tienen ciertas "ventajas", casi todas a nivel de proceso:
1) Son fáciles de definir, ya que no requieren análisis profundo (y por ende tiene a descuidarse la consistencia).
2) Ocupan menos espacio.
3) Se realizan JOINS rápidos (ya que la evaluación es a nivel de binarios), y por ende pueden obtenerse mejores performances en ciertos casos.
Tienen ciertos "defectos":
- No se puede hacer integración ni consolidación de sistemas sin complejos procesos de migración de datos con validaciones muy elaboradas.
- Traen problemas en los backup históricos.
- No son suficientemente identificatorios de la misma instancia de entidad en diferentes bases, porque no hay relación entre el ID y la entidad representada.
- Obligan a parametrizaciones adicionales en las búsquedas (que en definitiva sería lo mismo que usar claves naturales).
- Facilita el incorrecto manejo de las definiciones de ID en las tablas, ya que es habitual que el rango se desperdicie en un 50% (se crean enteros con signo, cuando un ID nunca puede ser negativo).
A mi personal entender, es un método "fácil" para los programadores, porque lo entienden, pero un dolor de cabeza para los arquitectos de datos.
Se puede decir mucho más, pero creo que eso te puede dar un pantallazo.
Obviamente, no estoy a favor de los autoincrementales. Especialmente porque los veo usar mal en casi todos los casos.
