¿Llaves naturales (Opinión)?
El día de ayer se me presentó un tema muy interesante al discutir si es o no correcto el utilizar llaves naturales como llaves primarias, seguidamente algunos ejemplos de llaves naturales:
- El número de cedula
- Seguro social
- Número de tarjeta
Ahora bien me gustaría saber sus opiniones y si están de acuerdo en utilizar las llaves naturales o en utilizar una llave subrogada como un ID autogenerado que no tenga nada que ver con dichas llaves naturales.
Themocracy
Para bases de datos preferiria usar llaves “subrogadas”, ya que yo veo que ese es el objetivo de dichas llaves, para relacionar las tablas. El hecho de que una cedula, por ejemplo, pueda servir de llave primaria es pura coinsidencia, yo la veria como un atributo de una persona.
Concuerdo en que no me gusta utilizarlas y estas son algunas razones:
1 Privacidad: al ser una llave primaria no solo exponemos el numero en la mencionada tabla, sino que si mantenemos relaciones con esa tabla(que raro suena eso de mantener relaciones XD) tendríamos que exponer ese numero en otras tables.
2 Control: Si utilizamos una llave externa hay que investigar y asegurarse de que nunca cambia y que siempre va a estar asociada a esta persona, como no tenemos control sobre eso si la llave por alguna extraña razón se modifica con el tiempo pues…
3 Unicidad: Hay muchos errores que asumen que los números que tenemos no se repiten nunca, se pueden dar casos extraños como este http://otrosmedios.elpais.com.uy/1969/12/31/por-un-error-de-registraduria-dos-mujeres-portaban-cedulas-identicas/
también hubo un caso de una señora cuyo numero de identificación, la cédula coincidía de alguna manera con el id de un extranjero con cuenta en el banco nacional. Y el señor se logueo y veía las cuentas de la señora. NO paso a mas porque realmente sin numero de pin y contraseña no puede hacer transferencias y porque el extranjero era un tipo honesto.Algo así fue la historia.
Por eso creo que el problema de usar números externos es la falta de control y la dependencia de que las asunciones que hacemos se mantengan ciertas a lo largo del tiempo.
Si yo también prefiero utilizar las llaves surrogadas debido a que si estas no se usan pueden causar muchos problemas como Neto ya lo dijo. Tales como datos flotando por quien sabe cuantas tablas ademas de que si existe la oportunidad de hacer un cambio en la llave como hacer el campo más grande este puede requerir que se modifiquen todas las tablas y no solo la principal tabla o tabla que contiene la llave primaria .
Gracias por responder.
Yo prefiero las artificiales hechas de algún metal no ferroso o alguna aleación como el acero o bronce.
A mi no me desagradan del todo ya que nos ahorramos campos, obtenemos el valor de inmediato lo que lleva a no hacer un join o where (combinaciones,multiplicaciones de datos) para ciertas consultas. En todo caso si estos tipos de campo ameritan para ser usado como clave primaria generalmente requiere unicidad e indenxación y serán los utilizado objetivamente para realizar las búsquedas.
Esto permite también tener tablas más “lógicas” y menos computacionales que para un mejor amarre con el mundo orientado a objetos al ser más naturales, donde las relaciones se dan (o deberían de dar a nivel de objetos y no de ligues).
La pregunta es que hacen esos campos en la tabla para que nos sirven todo depende de las circunstancias; también esta el caso de los ids autogenerados extra para las tablas con función de “intermedias” o las bases desnormalizadas. Es relativo.
Hay dos puntos en los que si se presentan posibles disconformidades: en el caso de la privacidad cuando un campo no debería de ser “visto” desde otras tablas y la otra por motivos de posibles modificaciones a ese campo clave (aunque esto no es nada del otro mundo para los SGBD modernos y bases de datos bien relacionadas que lo resuelven fácilmente pero algo lento para grandes volúmenes de datos).
Nota: Cuando vienen con llavero son más tuanis.
De hecho, nosotros hemos trabajado bastante en eso, para la identificación de pacientes, llegando a la conclusión de que la mejor opción son las llaves naturales. Y para mi la principal razón es mantener el control (como dice Ernesto), así validar que la misma base de datos no permita tener dos registros de personas virtualmente diferentes, que sean la misma…
Hay algunos aspectos que nos hicieron analizar la idea de las llaves subrogadas, por ejemplo para una funcionalidad nuestra: modificar numero de identificación. Entonces pensé en una tabla intermedia donde se fusionaran los numeros de identificacion, tanto “el viejo” como “el nuevo”, y así solo modificar el número de identificación en dicha tabla de asocie. Pero conociendo las experiencias de otros compañeros, esto ha servido para la duplicación de registros, desnormalización de la base de datos, además complicaría severamente una minería de datos, por ejemplo.