Início / dba / Perguntas / 15878
Accepted
Josh Darnell
Asked: 2012-03-31 09:05:48 +0800 CST

Preciso de uma coluna de ID separada para esta tabela de "mapeamento"?

  • 772

Eu tenho uma tabela de Producerse uma tabela de Products, ambas no formato:

  • Id- int, chave primária
  • Name- nvarchar

Um Produtor pode carregar vários Produtos, então eu ia criar uma tabela chamada ProducerDetailsque teria:

  • ProducerId- int, chave estrangeira paraProducers.Id
  • ProductId- int, chave estrangeira paraProducts.Id

Então comecei a me questionar, então pensei em perguntar aos especialistas. Seria melhor o design do banco de dados ter uma Idcoluna adicional (int, chave primária) na minha ProducerDetailstabela? Ou isso é desnecessário?

Estou usando o SQL-Server 2008 R2, se isso faz alguma diferença.

EDIT - A relação entre essas tabelas seria de muitos para muitos, acredito, desculpe não ter deixado isso claro. Um produtor pode transportar vários tipos de produtos e o mesmo produto pode ser produzido por vários produtores diferentes.

Peço desculpas se esta pergunta for excessivamente simples, integridade referencial / design de banco de dados não é meu ponto forte (embora eu esteja tentando melhorar isso).

sql-server database-design

2 respostas

  1. Não, não há valor em adicionar uma "chave primária" adicional a esta tabela. Suas junções só vão se referir a ProducerIDe ProductID, portanto, é apenas um peso morto. NA MINHA HUMILDE OPINIÃO.

    Embora eu concorde com @Shark que a tabela de junção nem parece ser necessária aqui, a menos que você esteja se esforçando para não alterar o esquema das tabelas existentes de forma alguma.

    Como um aparte, também acho que vale a pena nomear seu identificador primário por completo (por exemplo Products.ProductID, em vez de Products.ID) para que o identificador seja nomeado de forma consistente em todo o esquema.

    • 7
  2. Best Answer

    Se você tiver um relacionamento um-para-muitos entre Produtores e Produtos (em outras palavras, um produto só pode pertencer a um produtor), faria sentido apenas colocar uma referência de chave estrangeira diretamente em sua Productstabela:

    Um para muitos

    create table Producer
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table Product
(
    id int identity(1, 1) not null,
    Name varchar(100) not null,
    ProducerId int not null foreign key references Producer(id)
)
go

    Mas se houver uma chance de que seja um relacionamento muitos-para-muitos, sua melhor aposta seria usar uma tabela Join.

    Muitos para muitos

    create table Producer
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table Product
(
    id int identity(1, 1) not null primary key clustered,
    Name varchar(100) not null
)
go

create table ProductProducer
(
    ProductId int not null foreign key references Product(id),
    ProducerId int not null foreign key references Producer(id)
)
go

-- adding the primary key also ensures uniqueness
alter table ProductProducer
add constraint PK_ProductProducer 
primary key (ProductId, ProducerId)
go

    Se você decidir usar a tabela Join, não precisará ter uma chave adicional, pois a combinação de ProductId/ProducerIdseria única. Você poderia usá-los como uma chave composta, portanto, não precisaria desse Idcampo adicional em ProductProducer.

    • 6

relate perguntas