Relacionamento n x n: ID ou chave primária composta?
06/02/2013
0
Em uma modelagem de dados de NxN que resulta na tabela categoria_produto, qual as vantagens de se criar uma chave primária ID em contrapartida da chave primária composta? Melhor manutenção? Melhor performance?
CREATE TABLE categoria_produto ( cod_categoria INT NOT NULL, cod_produto INT NOT NULL, PRIMARY KEY (cod_categoria, cod_produto) ); CREATE TABLE categoria_produto ( id_categoria_produto INT NOT NULL cod_categoria INT NOT NULL, cod_produto INT NOT NULL, PRIMARY KEY (cod_categoria, cod_produto), UNIQUE (cod_categoria, cod_produto) );
Lowell Divaldo
Posts
20/02/2013
Alessandro Folk
Eu particularmente prefiro criar um ID para a tabela! e criar uma UNIQUE com os campos ID das tabelas relacionadas para garantir a integridade das informações...
Já passei por vários casos em que não ter um ID na tabela acabou dificultando as consultas ou a correção de problemas!
20/02/2013
Joel Rodrigues
21/02/2013
Robson Alves
Conceitualmente dizem que não é legal, fora a questão de mais joins, porém, facilita em algumas buscas.
Caso pesquise sobre isso, você verá que divergem as opiniões.
21/02/2013
Danilo Gomes
O índice servirá para o caso de pesquisar pela junção destas chaves, ou até mesmo por uma delas, dependendo do banco de dados.
O ID único facilita o desenvolvedor. Por exemplo, para referenciar essa associação num relatório, terá um identificador simples.
25/02/2013
Alessandro Folk
O índice servirá para o caso de pesquisar pela junção destas chaves, ou até mesmo por uma delas, dependendo do banco de dados.
O ID único facilita o desenvolvedor. Por exemplo, para referenciar essa associação num relatório, terá um identificador simples.
Exatamente!!!
25/02/2013
Caio Uechi
na minha opinião, o unico beneficio de criar chave primaria composta é que vc pode colocar pode alinhar com 'regras de negócios' , por exemplo vc tem o nome de um usuário e o CPF dele, e quer que garantir que o sistema só possua um usuário com um nome x + cpf y.. dai se pode usar a chave composta par auxiliar nesse tratamento...
BUT, WHATEVER....
hoje em dia eu não me preocupo com armazenamento, e sim com performance.
a maioria dos meus clientes querem saber de busca rápida e ponto final. =O!
02/04/2013
Vicente Alves
Isto posto, acredito que a único situação onde não há ganhos em se utilizar um ID é justamente o caso das tabelas N x N. Tabelas que servem apenas para manter a relação N x N não trazem nenhuma informação adicional. Usar mais um ID nesta tabela não acrescentaria nada ao modelo.
Porém, no caso de tabelas associativas, quando há atributos adicionais específicos da relação, se justifica criar um ID próprio, pois a tabela passa a manter informações adicionais. O ID passa a representar o conteúdo próprio da relação.
24/07/2013
Singular Ti
10/11/2013
Felipe Rosa
Isto posto, acredito que a único situação onde não há ganhos em se utilizar um ID é justamente o caso das tabelas N x N. Tabelas que servem apenas para manter a relação N x N não trazem nenhuma informação adicional. Usar mais um ID nesta tabela não acrescentaria nada ao modelo.
Porém, no caso de tabelas associativas, quando há atributos adicionais específicos da relação, se justifica criar um ID próprio, pois a tabela passa a manter informações adicionais. O ID passa a representar o conteúdo próprio da relação.
Mas, vamos supor que momento em que foi criada, a tabela não apresenta atributos adicionais, mas depois com a expansão do software se torne necessário, o que fazer?
11/11/2013
Vicente Alves
Isto posto, acredito que a único situação onde não há ganhos em se utilizar um ID é justamente o caso das tabelas N x N. Tabelas que servem apenas para manter a relação N x N não trazem nenhuma informação adicional. Usar mais um ID nesta tabela não acrescentaria nada ao modelo.
Porém, no caso de tabelas associativas, quando há atributos adicionais específicos da relação, se justifica criar um ID próprio, pois a tabela passa a manter informações adicionais. O ID passa a representar o conteúdo próprio da relação.
Mas, vamos supor que momento em que foi criada, a tabela não apresenta atributos adicionais, mas depois com a expansão do software se torne necessário, o que fazer?
Entendo que este será o momento de se refatorar a base de dado e o software acrescentando-se o ID. Até então, quando os registros não continham informações específicas da relação, não haveria a necessidade de se exportar o registro, pois este não possuia significado próprio.
Mas como foi dito, não há uma receita pronta que se aplique a todas as situações. Particularmente, acredito numa das práticas das metodologias ágeis que sugere que a simplicidade é o melhor negócio e que não devemos nos antecipar às mudanças. Há um autor, Donald Knuth, que diz: "Devemos esquecer as pequenas eficiências em 97% do tempo: otimização prematura é a raiz de todo o mal".
Casos e casos...
15/05/2014
João Françozo
Nesse caso fazemos uma tabela associativa.
Nessa tabela tem apenas uma PK e duas PK, assim você não terá chave composta evita esse tipo de chave para melhorar performance. Se precisar criar mais tabelas podem criar sem medo quando mais tabelas melhor para filtrar.
Att
João Antonio
15/05/2014
João Françozo
Nesse caso fazemos uma tabela associativa.
Nessa tabela tem apenas uma PK e duas PK, assim você não terá chave composta evita esse tipo de chave para melhorar performance. Se precisar criar mais tabelas podem criar sem medo quando mais tabelas melhor para filtrar.
Att
João Antonio
15/05/2014
João Françozo
Nesse caso fazemos uma tabela associativa.
Nessa tabela tem apenas uma PK e duas PK, assim você não terá chave composta evita esse tipo de chave para melhorar performance. Se precisar criar mais tabelas podem criar sem medo quando mais tabelas melhor para filtrar.
Att
João Antonio
Clique aqui para fazer login e interagir na Comunidade :)