Es adecuada esta estructura?

[gnzsoloyo]

Es algo que he explicado en diversos posts, y tiene que ver con los el modelo E-R, y requiere una explicación algo extensa. Veremos si puedo ponerlo claramente:

En ninguna parte del los fundamentos del modelo Entidad-Relación, el fundamento delas bases de datos relacionales, se dice que una PK debe ser numérica y autoincremental. Lo que se dice es que una clave primaria debe surgir del análisis de la entidad representada en ese sistema, y debe ser usado como PK aquel atributo o conjunto de atributos que permita identificar unívocamente un único registro en una tabla.
Pero cuando habla de atributos, se está hablando de datos que son propios de la entidad. En el caso de una persona, serían su nombre, apellido, documento, edad, sexo, fecha de nacimiento y otros; en una factura, el numero de la misma, la sucursal de emisión, la fecha, la dirección y el resto de los datos. En definitiva, cada entidad que se representa tiene un conjunto de atributos, alguno o algunos de los cuales pueden servir para identificarlo.
Muchas veces, el identificador es evidente, como el numero de documento; en otros casos es menos evidente, como el numero de factura, el cual se repite en diferentes terminales de emisión en un mismo supermercado, o en las diferentes sucursales de una empresa. En esos casos debe apoyarse en algun dato adicional: el numero de caja, o el de sucursal.
Pero la mayoría de los programadores no piensa en términos de analisis de sistemas orientados a las bases de datos, por lo cual recurren a un sistema simple y fácil para ellos: Numerar los registros secuencialmente. Eso no es que viole el modelo E-R, pero omite varios pasos en el desarrollo de las bases de datos, y termina generando problemas a largo plazo. Lo hacen así porque es fácil de hacer, sin medir las consecuencias.
Es cierto que es mucho más fácil armar un ID numérico incremental, pero ese atributo es un agregado, no es parte de la entidad, con lo cual para poder mantener la consistencia y cardinalidad de los registros se requiere que haya validaciones extra, verificaciones y generación de índices adicionales, todos los cuales se pagan con performance.
Para que quede claro: Como no es un valor propio de la entidad, tu puedes terminar ingresando mil veces los datos de la misma persona en la misma tabla, simplemente porque cada vez que lo ingreses su ID será distinto. Para evitar duplicaciones de datos tienes que recurrir a verificar, por ejemplo, su numero de documento de identidad (y nacionalidad en ocasiones) a fin de no duplicarlo. Pero en ese caso, ¿por qué no usas directamente el documento como PK?
Precisamente allí surge la cosa: Cuando tienes una base distribuida, uno de los principales problemas es que el mismo dato, para idéntica tabla, puede terminar ingresando en diferentes bases con diferentes PK, porque cada conjunto de Ids depende de la base a donde se inserte, y no del objeto en si. Y luego, cuando quieres integrar los datos de dos bases.... simplemente se arma el caos.
Entre los fundamentos que se te explican en la universidad, cuando cursas base de datos, se dice que una PK debe identificar el objeto, en todo el universo de objetos de la misma clase. Esto significa que ese mismo registro yo debo poder portarlo de base en base, y de tabla en tabla sin necesidad de ningún dato adicional a si mismo para ser identificable.
Obviamente eso, con un ID numérico y autoincremental es imposible.
A esto puedes agregarle que un ID autoincremental depende de la definición de la tabla, de su base y del servidor, y que si realizas determinados borrados, el valor puede reiniciarse, lo que trae problemas para mantener la consistencia histórica de los datos. Como además depende de la definición de la tabla, es susceptible a errores de creación de la tabla en diferentes locaciones, ya que el rango representable de claves depende del tipo de dato usado, y no de su atributo de auto_increment.

Como nota: En el estudio de las bases de datos se explica puntualmente que los ID numéricos, incrementales o no, sólo se deben usar si llegados a la 3FN en su normalización, no se ha encontrado un determinante que pueda ser CC.

En definitiva, los problemas que puede traer el uso de un ID numérico autoincremental pueden ser:
- No permite consolidar datos entre diferentes bases, por solapamiento de numeraciones.Esto trae problemas para definir datamarts o datawarehouses.
- No conserva la secuencialidad de las claves si se reinicia la tabla.
- No permite correctas restauraciones de datos a partir de backups.
- No es un identificador confiable para los objetos, ya que sólo define la unicidad del registro y no de su contenido.
- Obliga a generar validaciones extra en los datos.
- No guarda relación con los ordenamientos necesarios para las consultas.
- La eliminación de registros deja "huecos" de numeración que no deben ser usados (esto resulta frustrante a los programadores).
- Obliga a usar índices adicionales para lograr consultas optimizadas (las PK es lo primero en ser leído, y si no contiene datos relevantes termina siendo data inútil).

Cuando adquieres experiencia en el uso de PK no autonuméricas, empiezas a entender que las ventajas que proveen superan por mucho las exigencias de implementarlas.

Ahora bien, si tienen esos problemas, ¿por qué se usan y en los manuales aparecen este tipo de PK?
Bueno, la respuesta es simple:
1) Son fáciles de entender.
2) Son sencillos de crear.
3) Son simples de usar.
4) Los programadores de aplicaciones los comprenden sin problemas.
5) Parecen "naturales" a los usuarios sin estudios formales.
6) Todos los lenguajes de programación tienen funciones para aprovecharlas.

Personalmente, y por experiencia, las considero una pésima opción porque tarde o temprano te encontrarás con problemas originados por ellas. Si no es así, entonces tuviste suerte o tu sistema no creció lo suficiente.