tablas - tabla de rompimiento sql
MS SQL creando una relación de muchos a muchos con una tabla de unión (3)
Hay diferentes escuelas de pensamiento sobre esto. Una escuela prefiere incluir una clave principal y nombrar a la tabla de enlaces algo más importante que solo las dos tablas a las que está vinculado. El razonamiento es que aunque la tabla puede comenzar pareciendo simplemente una tabla de enlaces, puede convertirse en su propia tabla con datos significativos.
Un ejemplo es un muchos a muchos entre revistas y suscriptores. Realmente ese enlace es una suscripción con sus propios atributos, como fecha de vencimiento, estado de pago, etc.
Sin embargo, creo que a veces una tabla de enlaces es solo una tabla de enlaces. La relación de muchos a muchos con las categorías es un buen ejemplo de esto.
Entonces, en este caso, no es necesaria una clave principal de un campo separado. Podría tener una clave de asignación automática, que no dañaría nada, y facilitaría la eliminación de registros específicos. Puede ser una buena práctica general, por lo que si la tabla se convierte más adelante en una tabla significativa con sus propios datos significativos (como suscripciones), ya tendrá una clave principal de asignación automática.
Puede poner un índice único en los dos campos para evitar duplicados. Esto incluso evitará duplicados si tiene una clave de autoasignación separada. Puede usar ambos campos como su clave principal (que también es un índice único).
Por lo tanto, la única escuela de pensamiento puede atenerse a las claves primarias de asignación automática de enteros, y evita las claves primarias compuestas. Esta no es la única forma de hacerlo, y quizás no sea la mejor, pero no lo llevará a equivocarse, a un problema en el que realmente se arrepiente.
Pero, para algo como lo que estás haciendo, probablemente estarás bien con solo los dos campos. Todavía recomendaría que los dos campos sean una clave primaria compuesta, o al menos poner un índice único en los dos campos.
Estoy utilizando Microsoft SQL Server Management Studio y, al crear una tabla de unión, ¿debo crear una columna de ID para la tabla de unión? ¿O simplemente mantener 2 columnas para las tablas a las que me estoy uniendo en la relación muchos a muchos?
Por ejemplo, si estas serían las tablas de muchos a muchos:
MOVIE
Movie_ID
Name
etc...
CATEGORY
Category_ID
Name
etc...
Debería hacer la mesa de unión:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
Movie_Category_Junction_ID
[y haga de Movie_Category_Junction_ID mi clave principal y utilícelo como la columna de identidad]?
O:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
[y simplemente déjelo en eso sin clave primaria o tabla de identidad]?
Yo iría con la mesa de 2ª unión. Pero haz esos dos campos como clave principal. Eso restringirá las entradas duplicadas.
Yo usaría la segunda tabla de unión:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
La clave principal sería la combinación de ambas columnas. También tendría una clave externa de cada columna a la tabla Movie y Category .
La tabla de unión se vería similar a esto:
create table movie_category_junction
(
movie_id int,
category_id int,
CONSTRAINT movie_cat_pk PRIMARY KEY (movie_id, category_id),
CONSTRAINT FK_movie
FOREIGN KEY (movie_id) REFERENCES movie (movie_id),
CONSTRAINT FK_category
FOREIGN KEY (category_id) REFERENCES category (category_id)
);
Ver SQL Fiddle con Demo .
El uso de estos dos campos como PRIMARY KEY evitará que se agreguen combinaciones de películas / categorías duplicadas a la tabla.