¿Alguna vez crear una relación natural de ID o usar una IDENTIFICACIÓN interna y emular a los naturales de IDENTIFICACIÓN de la relación?[duplicar]

Question

Posibles Duplicados:
Sustituto Vs.Natural/Claves Empresariales

Si dadas dos tablas, Level1 [ID, Título, Número] Nivel2 [ID, FKID???, El Título, El Número]

Un usuario de que el sistema entiende que Nivel2 está relacionado con Nivel1 con base en Level1 del Número, mi pregunta es, que haría la relación basada en el IDENTIFICADOR interno y "emular" la relación con el "Número" o simplemente utilizar el "Número" de campo y hacer con ella?

Answer 1

Las dos razones estándar para relacionar en base de datos ID en lugar de ID natural son:

1. Es difícil garantizar que el ID natural nunca va a cambiar bajo ninguna circunstancia
2. En general, un ID naturales requiere más espacio y no es tan eficiente como el índice de base de datos ID (aunque por supuesto esto no es fuerte y rápido - que depende de los datos que constituyen su identificación natural). Mediante el uso de la base de datos ID, se puede evitar la duplicación de datos de la empresa.

Answer 2

Esta discusión ha sido golpeado hasta la muerte por aquí.Poca gente defiende natural solo las teclas y la mayoría de los anime sustituto de uso de la clave.Algunos dicen que usted puede tener ambos, lo cual es cierto, por supuesto (el uso natural de teclas para que el negocio se aplican reglas.)

Tiendo a pensar dos veces si la clave natural es en realidad una clave (la mayoría del tiempo no lo es.).Si es así, entonces yo lo uso.

Pero, de nuevo, la mayoría de las claves naturales en realidad no son llaves y duplicados debido a diversas razones.Por ejemplo, en países donde las tarjetas nacionales de identidad emitidos, no es infrecuente encontrar a dos personas con el mismo número de identificación.

Dicho esto, si me gustaría ir el sustituto de la clave de la ruta, me gustaría configurar las tablas como esta

Level1 [ID, Title, Number] Level2 [ID, FKID references Level1]

No hay necesidad de almacenar el título y el número dos veces.

Answer 3

creo que esto ha sido cubierto muchas veces.

Casi siempre es más seguro utilizar una identidad / Autonumérico como clave externa.

La mayoría de las teclas naturales pueden ser duplicadas (incluso si por error).

En mi país aún tiene problemas con los números de identificación personal de personas X -).

Answer 4

Si la columna 'Número' se puede utilizar para correlacionar las dos tablas de una manera natural, no lo fuerce la relación basada en una clave interna (sustituto).

Por un lado, la columna 'Número' podría ser lo suficientemente bueno, lo que no sería un desperdicio de espacio con la columna ID. Por otra parte, si la columna 'Número' no tiene las características adecuadas (cambio de poder, podría ser difícil de índice, etc), entonces el ID sustituto podría ser una mejor opción.

Todo se reduce a la semántica de la columna 'Número'.

Answer 5

• A veces la mejor manera de utilizar un producto natural tecla si (por ejemplo SSN, o Identificación de empleado) tiene la seguridad de clave estabilidad.

• Con claves suplentes, un FK es esencialmente una relación de uno # generado por el sistema, a otro sistema generado #. En un caso extremo, tal una relación artificial puede ser completamente fuera de sincronía con la realidad.

• Los otros críticos han comentado sobre el desorden que ocurre cuando una clave natural tiene que cambiar. Seguro eso es un problema. Pero vale la pena examinar la frecuencia con estas excepciones van a suceder para usted - si la cola (excepciones) mover al perro (su diseño) - en todos los casos

• No soy fanática de esto, pero estoy de acuerdo su incómodo tener diferentes convenciones dentro de la misma db con una mezcla de claves naturales y sustitutos.

• Si la clave natural es varios campos , Decir DateOfBirth + Apellido + Departamento (o algo parecido extraño cosa), entonces es mejor usar llaves artificiales.

Todos los argumentos anteriores son en el nivel lógico de un modelo de datos. En el nivel físico de su situación, los servidores y las limitaciones de rendimiento dictarán sus decisiones. Su mejor no Optimizar de forma prematura.