database-design - what - projects django

Compuesto clave primaria o no?

Question

Esto es lo que me confunde. A menudo tengo claves primarias compuestas en tablas de bases de datos. El lado negativo de este enfoque es que tengo bastante trabajo adicional cuando borro o edito entradas. Sin embargo, creo que este enfoque está en el espíritu del diseño de la base de datos.

Por otro lado, hay amigos míos, que nunca usan claves compuestas, sino que introducen otra columna de ''id'' en una tabla, y todas las demás claves son solo FK. Tienen mucho menos trabajo al codificar los procedimientos de eliminación y edición. Sin embargo, no sé cómo conservan la singularidad de las entradas de datos.

Por ejemplo:
Camino 1

create table ProxUsingDept (
fkProx int references Prox(ProxID) NOT NULL,
fkDept int references Department(DeptID) NOT NULL,
Value int,
PRIMARY KEY(fkProx,fkDept)
)

Camino 2

create table ProxUsingDept (
ID int NOT NULL IDENTITY PRIMARY KEY
fkProx int references Prox(ProxID) NOT NULL,
fkDept int references Department(DeptID) NOT NULL,
Value int
)

¿Qué camino es mejor? ¿Cuáles son los aspectos negativos del uso del enfoque 2? ¿Alguna sugerencia?

Answer 1

Haces las siguientes preguntas:

Sin embargo, no sé cómo conservan la singularidad de las entradas de datos.

La singularidad se puede preservar declarando un índice UNIQUE compuesto separado en las columnas que de otro modo formarían la clave primaria natural.

¿Qué camino es mejor?

Diferentes personas tienen opiniones diferentes, a veces fuertemente sostenidas. Creo que encontrará que más personas usan claves enteras sustitutas (no eso hace que sea la solución "correcta").

¿Cuáles son los aspectos negativos del uso del enfoque 2?

Estas son algunas de las desventajas de usar una clave sustituta:

1. Necesita un índice adicional para mantener el carácter único de la clave principal natural.

2. A veces, se requieren JOIN adicionales cuando se seleccionan los datos para obtener los resultados que desea (esto sucede cuando puede satisfacer los requisitos de la consulta utilizando solo las columnas de la clave natural compuesta; en este caso, puede usar las columnas de clave externa en lugar de ÚNETE de vuelta a la mesa original).

Answer 2

Hay casos como M: N en tablas donde las claves compuestas tienen más sentido (y si la naturaleza o el enlace M: N cambian, tendrá que volver a trabajar esta tabla de todos modos).

Answer 3

Personalmente, prefiero su segundo enfoque (y lo usaría casi el 100% del tiempo): introduzca un campo de ID sustituto.

¿Por qué?

• hace la vida mucho más fácil para cualquier tabla que haga referencia a su tabla: las condiciones de UNIR son mucho más simples con solo una columna de ID (en lugar de 2, 3 o incluso más columnas a las que debe unirse, todo el tiempo)

• hace la vida mucho más fácil ya que cualquier tabla que haga referencia a su tabla solo necesita llevar una ID única como campo de clave externa, no varias columnas de su clave compuesta

• hace la vida mucho más fácil ya que la base de datos puede manejar la creación de una columna de ID única (usando INT IDENTITY )

Sin embargo, no sé cómo conservan la singularidad de las entradas de datos.

Muy simple: ¡ponga un ÍNDICE ÚNICO en las columnas compuestas que de otra manera usaría como su clave principal!

CREATE UNIQUE INDEX UIX_WhateverNameYouWant
ON dbo.ProxUsingDept(fkProx, fkDept)

Ahora, su mesa garantiza que nunca habrá un par duplicado de (fkProx, fkDept) en su mesa - ¡problema resuelto!

Answer 4

Sé que ha pasado mucho tiempo desde que se hizo esta publicación. Pero tuve que encontrar una situación similar con respecto a la clave compuesta, así que estoy publicando mis pensamientos.

Digamos que tenemos dos tablas T1 y T2.

T1 tiene las columnas C1 y C2.

T2 tiene las columnas C1, C2 y C3.

C1 y C2 son las claves primarias compuestas para la tabla T1 y las claves externas para la tabla T2.

Supongamos que utilizamos una clave sustituta para la Tabla T1 (T1_ID) y la usamos como Clave externa en la tabla T2, si los valores de C1 y C2 de la Tabla T1 cambian, es un trabajo adicional para imponer la restricción de integridad referencial en la Tabla T2, ya que solo estamos viendo la clave sustituta de la Tabla T1 cuyo valor no cambió en la Tabla T1. Este podría ser un problema con el segundo enfoque.