Relacionamento n x n: ID ou chave primária composta?

06/02/2013

0

Boa noite pessoal!

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

Lowell Divaldo

Responder

Posts

20/02/2013

Alessandro Folk

Boa noite!
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!
Responder

20/02/2013

Joel Rodrigues

Eu, particularmente, prefiro criar uma chave composta. É um campo a menos, um índice a menos, um identity a menos, etc. Como dificilmente também se usa esse campo para buscas, não vejo necessidade.
Responder

21/02/2013

Robson Alves

Eu gosto de tabela associativa!
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.
Responder

21/02/2013

Danilo Gomes

Eu concordo com o Alessandro, prefiro criar um ID que identifique a relação e um índice unique para as chaves relacionadas.

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.
Responder

25/02/2013

Alessandro Folk

Eu concordo com o Alessandro, prefiro criar um ID que identifique a relação e um índice unique para as chaves relacionadas.

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!!!
Responder

25/02/2013

Caio Uechi

cara se vc quer performance, não utilize chave primaria composta!!

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!
Responder

02/04/2013

Vicente Alves

Entendo que qualquer tabela que possa ser associada a um objeto do mundo real deva possuir um identificador interno. É um padrão que facilita absurdamente a manutenção. A regra é nunca ter uma "chave falante" ou uma "chave inteligente".

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.
Responder

24/07/2013

Singular Ti

Concordo com você Vicente Alves, depende muito do caso... Se a tabela não apresenta atributos adicionais não vejo o porque ter um ID para ela... Enfim!
Responder

10/11/2013

Felipe Rosa

Entendo que qualquer tabela que possa ser associada a um objeto do mundo real deva possuir um identificador interno. É um padrão que facilita absurdamente a manutenção. A regra é nunca ter uma "chave falante" ou uma "chave inteligente".

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?
Responder

11/11/2013

Vicente Alves

Entendo que qualquer tabela que possa ser associada a um objeto do mundo real deva possuir um identificador interno. É um padrão que facilita absurdamente a manutenção. A regra é nunca ter uma "chave falante" ou uma "chave inteligente".

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?
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...
Responder

15/05/2014

João Françozo

Boa Tarde

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
Responder

15/05/2014

João Françozo

Boa Tarde

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
Responder

15/05/2014

João Françozo

Boa Tarde

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
Responder

Que tal ter acesso a um e-book gratuito que vai te ajudar muito nesse momento decisivo?

Ver ebook

Recomendado pra quem ainda não iniciou o estudos.

Eu quero
Ver ebook

Recomendado para quem está passando por dificuldades nessa etapa inicial

Eu quero

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar