tabla - llave foranea compuesta sql server
SQL-clave principal de la tabla many-to-many (4)
Con un mapeo simple de dos columnas de muchos a muchos, no veo ninguna ventaja real de tener una clave sustituta. Tener una clave principal (col1,col2) está garantizada como única (suponiendo que los valores col1 y col2 en las tablas referenciadas son únicos) y un índice separado en (col2,col1) capturará aquellos casos en los que la orden contraria se ejecutará más rápido. El sustituto es una pérdida de espacio.
No necesitará índices en las columnas individuales, ya que la tabla solo debe utilizarse para unir las dos tablas a las que se hace referencia.
Ese comentario al que se refiere en la pregunta no vale los electrones que usa, en mi opinión. Parece que el autor cree que la tabla se almacena en una matriz en lugar de una estructura de árbol multidireccional equilibrada de alto rendimiento.
Para empezar, nunca es necesario almacenar o clasificar la mesa , solo el índice. Y el índice no se almacenará de forma secuencial, se almacenará de manera eficiente para poder recuperarlo rápidamente.
Además, la gran mayoría de las tablas de la base de datos se leen con mucha más frecuencia que las escritas. Eso hace que cualquier cosa que hagas en el lado selecto sea mucho más relevante que cualquier cosa en el lado de la inserción.
Esta pregunta surge después de leer un comentario en esta pregunta:
Cuando crea una tabla de varios a muchos, debe crear una clave primaria compuesta en las dos columnas de clave externa, o crear una clave primaria sustituta de "ID" de aumento automático, y simplemente colocar índices en sus dos columnas FK (y tal vez una restricción única)? ¿Cuáles son las implicaciones en el rendimiento para insertar nuevos registros / volver a indexar en cada caso?
Básicamente, esto:
PartDevice
----------
PartID (PK/FK)
DeviceID (PK/FK)
contra esto:
PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)
El comentarista dice:
hacer que los dos ID sean PK significa que la tabla está clasificada físicamente en el disco en ese orden. Entonces si insertamos (Part1 / Device1), (Part1 / Device2), (Part2 / Device3), entonces (Parte 1 / Device3) la base de datos tendrá que separar la tabla e insertar la última entre las entradas 2 y 3. Para muchos registros, esto se vuelve muy problemático ya que implica mezclar cientos, miles o millones de registros cada vez que se agrega uno. Por el contrario, un PK autoincrementable permite que los nuevos registros se agreguen al final.
La razón por la que estoy preguntando es porque siempre me he sentido inclinado a hacer la clave primaria compuesta sin una columna de autoincremento de sustitución, pero no estoy seguro de si la clave sustituta es realmente más eficiente.
La forma más breve y directa en que puedo responder a su pregunta es decir que habrá un impacto en el rendimiento si las dos tablas que está vinculando no tienen claves primarias secuenciales. Como indicó / citó, el índice de la tabla de enlaces se fragmentará o el DBMS trabajará más para insertar registros si la tabla de enlaces no tiene su propia clave primaria secuencial. Esta es la razón por la cual la mayoría de las personas coloca una clave principal de incremento secuencial en las tablas de enlaces.
No se necesita una clave sustituta para las tablas de enlaces.
Un PK activado (col1, col2) y otro índice único en (col2, col1) es todo lo que necesita
A menos que use un ORM que no puede hacer frente y dicta su diseño de base de datos para usted ...
Editar: respondí lo mismo aquí: SQL: ¿necesita una clave primaria autoincremental para muchas tablas muchas?
Una clave primaria incremental podría ser necesaria si se hace referencia a la tabla. Puede haber detalles en la tabla de muchos a muchos que deben extraerse de otra tabla utilizando la clave primaria incremental.
por ejemplo
PartDevice
----------
ID (PK/auto-increment)
PartID (FK)
DeviceID (FK)
Other Details
Es fácil extraer los ''Otros detalles'' utilizando PartDevice.ID como FK. Por lo tanto, se necesita el uso de clave primaria incremental.