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

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:

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

@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

@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

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

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