Quais vantagens temos ao criar uma tabela de mapeamento separada para duas tabelas relacionais

9

Em vários CMS de código aberto, notei que há uma tabela separada para mapear duas tabelas relacionais. Como para categorias e produtos, há uma product_category_mappingtabela separada . Esta tabela possui apenas uma chave primária e duas chaves estrangeiras das categorias e tabelas de produtos.

Minha pergunta é quais são os benefícios desse design de banco de dados, em vez de apenas vincular as tabelas diretamente, definindo uma chave estrangeira em ambas as tabelas? É apenas uma questão de conveniência?

database-design database-development Pankaj Upadhyay
fonte

Respostas:

7

Essa tabela geralmente é chamada de tabela de link ou tabela de bridge .

É a maneira padrão de criar um relacionamento de muitos para muitos. Com uma chave estrangeira direta entre as duas tabelas, você pode criar apenas um relacionamento um para muitos (porque a chave primária que a chave estrangeira aponta também é uma restrição exclusiva) ou um relacionamento um para um (se o chave estrangeira em si também é uma restrição exclusiva).

Dependendo da filosofia de design do banco de dados, a coluna de chave primária geralmente é deixada de fora e a chave primária da tabela de ponte é composta pelas próprias colunas de chave estrangeira (você precisa de uma restrição exclusiva nessas colunas, então por que não torná-la a chave primária?).

tdammers
fonte
ohh k .... Então, em suma, se eu preciso ter um relacionamento muitos-para-muitos, é preciso seguir essa abordagem, certo?
Pankaj Upadhyay
1
@PankajUpadhyay: Correto. Os relacionamentos de MM devem ser implementados dessa maneira.
NoChance
@PankajUpadhyay: em teoria, você pode usar outras abordagens, mas elas são confusas e erradas, por isso sugiro que você nunca vá lá.
tdammers
2
@PankajUpadhyay: Se você deseja criar um banco de dados Normalizado, use uma terceira tabela, conforme explicado. Se você tem um relacionamento 1-M, definitivamente não quer uma terceira mesa. Se você possui um MM finito e limitado e não se importa com a Normalização, pode ficar sem uma terceira tabela. Em geral, atenha-se a um banco de dados normalizado, a menos que você esteja construindo um armazém de dados ou um data mart (nesses casos, um esquema normalizado é discutível).
NoChance
@EmmadKareem: ya, eu vi que .... Meus requisitos são um-para-muitos, por isso não vou estar criando a tabela .... Graças companheiro
Pankaj Upadhyay
2

Essa é uma maneira fácil de implementar relacionamentos muitos para muitos .

Considere estas duas tabelas: 

category
--------
categoryID [PK]
categoryName

product
-------
productID [PK]
productName

Se você adicionar um categoryIDcampo a product, cada produto poderá ter apenas uma categoria. Mas se tivermos algo product_category_mappingassim:

product_category_mapping
------------------------
mappingID [PK]
productID [FK]
categoryID [FK]

então podemos ter:

mappingID  productID  categoryID
--------------------------------
1          1          1
2          1          2
3          2          3
4          2          1

Portanto, o produto 1 é da categoria 1 e 2 e o produto 2 é da categoria 3 e 1, muitos produtos pertencem a muitas categorias e muitas categorias têm muitos produtos.

Como escreve o tdammers , essa tabela é frequentemente referida como tabela de links ou tabela de bridge, e eu até a vi referida como tabela HABTM, de HasAndBelongsToMany, que aparentemente é Ruby on Rails, fala de muitos para muitos. E a Wikipedia a chama de tabela de junção e tem mais alguns nomes para ela.

yannis
fonte
Não é apenas o Rails-speak, praticamente todas as estruturas PHP que usei se referem a ele como HABTM.
sevenseacat
@Karpie Alguns exemplos? Eu sei que o CakePHP usa o nome HABTM, mas começou como um clone do Rails.
yannis
Eu sou um grande fã de substitutos. Mas eu prefiro deixar de fora a chave substituta extra "mappingID" e colocar uma PK composta em "productID" e "categoryID". Em minha mente, a chave composta composta por 2 substitutos é uma substituta por si só. Você nunca realmente usará o "mappingID" substituto em qualquer associação.
Lord Tydus
@ LordTydus Eu não escrevi sobre a chave composta como o Tdammers, não há motivo para reciclar sua resposta. Mas existem usos válidos para a mappingIDchave, um cenário comum é acompanhar melhor as importações / exportações em massa, nas quais a tabela de junções contém muitas chaves estrangeiras.
yannis
2

O motivo para usar uma tabela de mapeamento é eliminar a duplicação. Vá em frente e tente outra técnica de mapeamento. Você não poderá impedir a duplicação de dados sem eles.

E isso traz uma pergunta 2cd. Por que se preocupar em eliminar a duplicação? Então você só precisa editar os dados uma vez em um só lugar. Às vezes, há penalidades de desempenho para eliminar a duplicação. Outras vezes, há desempenho AUMENTADO para eliminar a duplicação. Por exemplo, é mais rápido preencher uma lista suspensa com valores de pesquisa normalizados do que selecionar valores duplicados distintos em uma tabela grande.

Lord Tydus
fonte