E no lance de relacionamento n:m

[tabela1]    n:m    [tabela2]

[tabela de relacionamento]

a tabela de relacionamento no caso não seria melhor se fosse criada uma
chave primaria composta?

Em 27/03/08, Evandro Ricardo Silvestre <[EMAIL PROTECTED]>
escreveu:
>
> Leandro DUTRA wrote:
> > 2008/3/26, Fernando Brombatti <[EMAIL PROTECTED]>:
> >
> >> Eu, particularmente, acho que chave primária não pode, jamais, ser
> composta.
> >> Chave primária é primária e basta!
> >>
> >
> > Mas Fernando, o que tem a ver chave primária ser simples ou composta?
> > Qual o problema?
> >
> > Se você tem uma chave composta perfeitamente boa, para que aumentar a
> > complexidade do modelo, criar um índice adicional, gastar mais
> > armazenamento, cache e eventos de E/S?  Você vai ter de declarar a
> > chave composta mesmo também…
> >
>
> Concordo com relação a chave composta perfeitamente boa, mas não
> concordo que criar uma chave primária quando se pode ter uma chave
> composta vai aumentar tanto assim eventos de E/S e gasto de
> armazenamento. Por outro lado pode até diminuir, eu tendo uma chave
> primária aumentando a cache e eventos E/S na tabela, vou diminuir o
> mesmo em tabelas relacionadas, pois não precisarei ter todos os da chave
> composta na relação. Se uma tabela tem mais de 1 relacionamento, acho
> que vamos ganhar em E/S ao invés de perder. Perde-se na tabela
> principal, mas ganha nas relações. Trade-off, ai seria o caso de
> balancear onde é melhor perder.
>
>
> Evandro
>
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



-- 
=============================================================
Grupo Comunidade de Comunicação
Rafael Lúcio 29809.099333,
fazendo do seu website uma aplicação em tempo real
ms xsl js(dom) css xhtml php mysql pgsql ajax json smarty drupal
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a