Ni SQL ni el modelo relacional se ven perturbados por claves externas que hacen referencia a una clave natural. De hecho, hacer referencia a claves naturales a menudo mejora drásticamente el rendimiento. Te sorprendería con qué frecuencia la información que necesita está completamente contenida en una clave natural; hacer referencia a esa tecla intercambia una unión por una tabla más amplia (y, en consecuencia, reduce el número de filas que puede almacenar en una página).
Por definición, la información que necesita siempre está completamente contenida en la clave natural de cada tabla de "búsqueda". (El término tabla de búsqueda es informal. En el modelo relacional, todas las tablas son solo tablas. Una tabla de códigos postales de EE. UU. Puede tener filas como esta: {AK, Alaska}, {AL, Alabama}, {AZ, Arizona} , etc. La mayoría de la gente llamaría a eso una tabla de búsqueda).
En sistemas grandes, no es inusual encontrar tablas que tengan más de una clave candidata. Tampoco es inusual que las tablas que sirven a una parte de la empresa hagan referencia a una clave candidata, y las tablas que sirven a otra parte de la empresa para hacer referencia a una clave candidata diferente. Este es uno de los puntos fuertes del modelo relacional, y es parte del modelo relacional que SQL admite bastante bien.
Te encontrarás con dos problemas cuando hagas referencia a claves naturales en tablas que también tienen una clave sustituta.
Primero, sorprenderás a la gente. Aunque generalmente presiono fuertemente por el Principio de Menos Sorpresa , esta es una situación en la que no me importa sorprender a las personas. Cuando el problema es que los desarrolladores están sorprendidos por el uso lógico de claves externas, la solución es la educación, no el rediseño.
En segundo lugar, los ORM generalmente no están diseñados en torno al modelo relacional, y a veces incorporan supuestos que no reflejan las mejores prácticas. (De hecho, a menudo parecen estar diseñados sin contar con la entrada de un profesional de la base de datos). Requerir un número de identificación en cada tabla es uno de esos supuestos. Otro supone que la aplicación ORM "posee" la base de datos. (Por lo tanto, es gratis crear, soltar y renombrar tablas y columnas).
He trabajado en un sistema de base de datos que sirvió datos a cientos de programas de aplicación escritos en al menos dos docenas de idiomas durante un período de 30 años. Esa base de datos pertenece a la empresa, no a un ORM.
Una bifurcación que introduce cambios importantes debería ser un show-stopper.
Medí el rendimiento con claves naturales y claves sustitutas en una empresa en la que solía trabajar. Hay un punto de inflexión en el que las claves sustitutas comienzan a superar a las claves naturales. (Suponiendo que no haya más esfuerzo para mantener alto el rendimiento de la clave natural, como particiones, índices parciales, índices basados en funciones, espacios de tablas adicionales, uso de discos de estado sólido, etc.) Según mis estimaciones para esa compañía, alcanzarán ese punto de inflexión en alrededor de 2045. Mientras tanto, obtienen un mejor rendimiento con claves naturales.
Otras respuestas relevantes: en el esquema de base de datos confuso
Si no sabe la respuesta, vaya con el sustituto. He aquí por qué: si se hacen suposiciones sobre las reglas de negocios, y esas suposiciones son falsas o las reglas cambian, sus datos son basura. Aquí hay un ejemplo:
Persona, Rol, Persona Rol
La regla comercial actual establece que una Persona tiene un Rol. Cree una tabla que vincule Person y Role donde PersonRole (PersonName, PersonBirthDate, PersonMotherMaidenName, ..., RoleCode)
¡Ahora eres un verdadero purista cuando se trata de Natural Keys! Pero en serio, ¿qué pasa si la organización decide que una persona ahora puede asumir múltiples roles? ¿Cuáles son los efectos posteriores de apoyar el cambio en las necesidades comerciales?
fuente