Estou usando o Microsoft SQL Server Management Studioe, ao criar uma tabela de junção, devo criar uma coluna de ID para a tabela de junção; em caso afirmativo, devo torná-la a chave primária e a coluna de identidade? Ou apenas manter 2 colunas para as tabelas que estou juntando na relação muitos-para-muitos?
Por exemplo, se estas forem as tabelas de muitos para muitos:
MOVIE
Movie_ID
Name
etc...
CATEGORY
Category_ID
Name
etc...
Devo fazer a mesa de junção:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
Movie_Category_Junction_ID
[e fazer o Movie_Category_Junction_ID minha chave primária e usá-la como a coluna de identidade]?
Ou:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
[e deixar por isso mesmo, sem chave primária ou tabela de identidade]?
Respostas:
42 para resposta № 1Eu usaria a segunda tabela de junção:
MOVIE_CATEGORY_JUNCTION
Movie_ID
Category_ID
A chave primária seria a combinação de ambas as colunas. Você também teria uma chave estrangeira de cada coluna para o Movie e Category mesa.
A tabela de junção seria semelhante a esta:
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)
);
Vejo SQL Fiddle com Demo.
Usando esses dois campos como o PRIMARY KEY irá evitar que combinações duplicadas de filmes / categorias sejam adicionadas à tabela.
16 para resposta № 2
Existem diferentes escolas de pensamento sobre isso.Uma escola prefere incluir uma chave primária e nomear a tabela de ligação com algo mais significativo do que apenas as duas tabelas que está ligando. O raciocínio é que, embora a tabela possa começar parecendo apenas uma tabela de ligação, ela pode se tornar sua própria tabela com dados significativos.
Um exemplo é um muitos para muitos entre revistas e assinantes. Na verdade, esse link é uma assinatura com atributos próprios, como data de vencimento, status de pagamento, etc.
No entanto, acho que às vezes uma tabela de ligação é apenas uma tabela de ligação. O relacionamento de muitos para muitos com as categorias é um bom exemplo disso.
Portanto, neste caso, uma chave primária separada de um camponão é necessário. Você poderia ter uma chave de atribuição automática, o que não faria mal a nada e tornaria a exclusão de registros específicos mais fácil. Pode ser uma boa prática geral, portanto, se a tabela posteriormente se desenvolver em uma tabela significativa com seus próprios dados significativos (como assinaturas) já terá uma chave primária de atribuição automática.
Você pode colocar um índice único nos dois campos paraevite duplicatas. Isso evitará até mesmo duplicatas se você tiver uma chave de atribuição automática separada. Você pode usar os dois campos como sua chave primária (que também é um índice exclusivo).
Então, a única escola de pensamento pode ficar cominteiro auto-atribui chaves primárias e evita chaves primárias compostas. Essa não é a única maneira de fazer isso, e talvez não a melhor, mas não vai te levar a um problema do qual você realmente se arrependerá.
Mas, para algo como o que você está fazendo, vocêprovavelmente ficará bem apenas com os dois campos. Eu ainda recomendaria tornar os dois campos uma chave primária composta ou, pelo menos, colocar um índice exclusivo nos dois campos.
0 para resposta № 3
Eu iria com a 2ª mesa de junção. Mas torne esses dois campos como chave primária. Isso irá restringir entradas duplicadas.