Teclas primarias compuestas e influencia en el uso de claves naturales/sustitutivas

Question

Tengo una pregunta bastante simple sobre el uso de claves naturales/sustitutas en un contexto bien definido que se manifiesta a menudo y que voy a ilustrar.

Supongamos que está diseñando el esquema de base de datos para un producto utilizando SQL Server 2005 como DBMS. En aras de la simplicidad, digamos que solo hay dos entidades involucradas, que se han asignado a 2 tablas, Maestro y Esclavo. Supongamos que :

1. podemos tener 0..n entradas esclavo por una sola fila de Maestro;
2. Conjunto de columna (A, B, C, D) en el maestro es el único candidato para clave primaria;
3. Columna B en Master es sujeto a cambios en el tiempo;
4. A, B, C, D son mix de columnas varchar, decimal y bigint.

La pregunta es: ¿cómo diseñaría las claves/restricciones/referencias para esas tablas? ¿Prefieres (argumenting su elección):

1. Implementar un compuesto natural clave sobre el Master en (A, B, C, D), y una clave externa compuesta relacionados con el esclavo, o
2. Introducir una clave sustituta K en Master, digamos una columna IDENTITY (1,1) con una clave foránea (de una sola columna) relacionada en Slave, agregando una restricción ÚNICA en Master (A, B, C, D) o
3. Utilice un enfoque diferente.

En cuanto a mí, me gustaría ir con la opción 2), principalmente por suposición 3) y por rendimiento, pero me gustaría escuchar la opinión de otra persona (ya que hay un debate bastante abierto sobre el tema)

agradecimiento

Answer 1

Cualquiera de 1,2 o 3. Hay ISN No es necesariamente suficiente información para determinar si un sustituto es necesario o qué tan útil podría ser. ¿Alguno de los atributos clave compuestos también es parte de alguna clave o restricción en la tabla de esclavos? ¿Hay alguna otra clave de Master que pueda usarse como clave foránea? El hecho de que un valor clave pueda cambiar no debe ser el factor decisivo, ya que cualquier valor clave puede tener que cambiar: los sustitutos no son una excepción.

hay todo un debate abierto sobre el tema

Por desgracia, gran parte de ese debate se basa en la suposición errónea de que tiene que elegir entre cualquiera de un sustituto o una clave natural. Como su opción 2 sugiere correctamente, puede usar ambas a medida que surja la necesidad. Uno no es un sustituto del otro porque las claves simples y las claves compuestas en diferentes atributos obviamente significan cosas diferentes en su modelo de datos y aplican diferentes restricciones en sus datos.

Answer 2

Su hipótesis (3) tiende opción para sugerir (2), ya que es incómodo y potencialmente mucho tiempo para hacer frente a cambios en cascada de la clave principal del Maestro cuando B cambia.

Por supuesto, depende de la frecuencia con que esto ocurra: si es algo que espera que suceda "todo el tiempo", sugiere (A, B, C, D) es una elección incorrecta de la clave principal; por otro lado, si raramente ocurre, entonces (A, B, C, D) puede ser una buena opción para la clave principal, y tener esas columnas en Esclavo puede tener algunas ventajas (no es necesario unirse para dominar todo el tiempo para descubrir esos valores de columna).

Answer 3

Me gustaría ir a la opción 2. Mantenerlo simple.

Marca las casillas (angostas, numéricas, inmutables, aumentando de forma estrictamente monótona) para un índice agrupado útil (que es el valor predeterminado de PK en SQL Server).

Debe forzar la exclusividad en A,B,C,D, para preservar la integridad de los datos, como se indica.

No hay nada conceptualmente incorrecto con la opción 1, pero tan pronto como requiera más índices en "maestro", la gran clave agrupada se convierte en una responsabilidad. O más trabajo para determinar qué índice es el mejor según lo agrupado.

Editar:

En caso de cualquier confusión

la elección de qué índice está agrupado es independiente a la elección de clave

Answer 4

Tres.

La primera sugerencia podría ser eliminar las claves de compost y agregar un nuevo campo para una clave automática, que no esté relacionado con los otros campos. Para dominar y detallar la tabla.

Podría ser una clave de autoincrementación entera o un Identificador único global. Mantener claves compuestas en cualquier S.Q.L. marca del servidor, es difícil y, a veces, innecesariamente difícil.

Pero, si necesita mantener la clave compuesta en la tabla maestra, aún puede preguntarse cómo lidiar con la clave primaria de la tabla esclava. Muchos desarrolladores usualmente toman los mismos campos para la clave primaria, desde la tabla maestra, la ponen en la tabla esclava/detalles y agregan una clave entera consecutiva adicional. Pero, como mencionas, si tienes que cambiar la clave de la tabla maestra y conservar las filas de detalles ya existentes, tienes problemas con las restricciones de integridad de referencia.

Resumen: sugiero que agregue un nuevo campo para la tabla esclava, que no esté relacionado con la tabla maestra, agregue una clave foránea de campos a la tabla esclava/de detalles, que haga referencia a la tabla maestra. Mantenga la tecla principal de detalle y la clave externa en la tabla maestra, independientemente.