Pregunta

Puede una clave compuesta puede establecer como una clave principal a otra mesa?

Por ejemplo tengo las tablas:

  • Books -con clave principal: Product_ID
  • Client -con Clave primaria: Client_ID
  • Clients_Books -con compuesto clave primaria: Product_Id y Client_ID

Quiero establecer esta clave primaria compuesta de Clients_Books como una clave principal de otra tabla llamada: Detalles_de_pedidos. Pero no quiero usar la ID_Producto y la client_id de los libros, mesas clientes.

¿Esto tiene sentido? Todas las opiniones más que bienvenido.

¿Fue útil?

Solución

La respuesta corta es, no - no puede hacer eso. Todas las columnas de la PK (u otra tecla alterna) deben aparecer en la definición FK. Asimismo, recuerda que una tabla puede tener varias claves - referido como claves candidatas (teclas veces alternas). La clave principal es simplemente la tecla "mejor" para su diseño / uso (normalmente el más estrecho uno - más pequeño en tamaño en bytes). Prefijamos el nombre de estos otros índices únicos como "AK_ {nombre}." - AK = Clave alternativo

Lo que hacemos en esta circunstancia es una de dos cosas:

  1. definir un PK sintetizado ser una columna de "Identidad" y, a continuación, agregar un índice único a la clave compuesta - teniendo así dos "claves" en la tabla. Todas las tablas secundarias a continuación definen el FK como señalar a la columna de identidad PK lo sintético.
  2. Deje la llave compuesto como es. Definirlo como el PK en esa tabla maestra, y hacer todos FKs tienen la misma definición.

En general no es una buena idea tener varias tablas con la misma definición de PK (es decir, PKs que también son claves ajenas a otra tabla). Digo "generalmente" - es importante entender la definición de sus Entidades

.

Así que ¿por qué utilizar # 1? La pregunta que me hago es si la tecla compuesto es realmente los datos de las define la fila? Es esa llave compuesto realmente la definición de una fila o se trata más de una FK a alguna otra información? Si es más de un FK entonces creo el PK sintetizado (Identidad). Es una Orden en realidad los libros que posee un cliente? Una orden puede hacer que un cliente de poseer un nuevo libro -. Pero puede no ser la misma cosa

Tener el PK sintetizado ofrece algunas opciones más en el futuro en los próximos años. Si la relación tiene que cambiar en su mesa Client_Books entonces es posible aislar los cambios en otras tablas.

Por ejemplo - ¿y si un cliente puede poseer más de una copia de un libro - ¿cómo va a poner en práctica eso? Con la tecla sintetizado puede simplemente eliminar el índice único en la clave compuesta y dejarlo como un simple FK, entonces la tabla Detalles_de_pedidos simplemente representaría cuando un cliente compró su segunda copia. Sin embargo, si se hubiera tomado la clave compuesta en la ruta de órdenes, entonces usted tendría que encontrar la manera de redefinir Order_Detail, así como Client_Books (y cualquier otra FKs que apuntaban a Order_Detail).

También le pediría que evaluar si un Order_Detail es realmente un Client_Book? Normalmente una orden hace que el cliente de entrar en posesión de un nuevo libro. Creo que de las órdenes como independiente del inventario -. Por lo tanto, la PK en Order_Detail no debe ser el PK en Client_Books, Order_Detail debe probablemente tiene su propio PK independiente

Otros consejos

Se puede ir en un camino oscuro y sucio. No haga esto. Se adhieren a las mejores prácticas. - utilizar una clave primaria simple en la tabla, y luego tener una clave externa si es necesario a otras tablas

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top