Le 19 février 2015 22:27:07 GMT-02:00, Everton Berz <[email protected]> a écrit : >Sua modelagem está confusa.
Em quê? >Existem outros jeitos de resolver, mas não quer optar por usar chaves >artificiais? Pelo contrário, ele só usou chaves artificiais, e dentro desse conceito adequadamente. O problema é que o conceito de chaves artificiais é insuficiente: nunca pode substituir completamente a declaração de ao menos uma chave natural. >Se eu entendi teu problema, acredito que a modelagem abaixo resolva. Pode até resolver o problema que ele colocou (não analisei isso), mas quanto à declaração de chaves primárias o teu está muito pior que o dele. Não faz sentido criar uma chave artificial para substituir uma chave composta de chaves estrangeiras: o modelo engorda, fica mais difícil de entender, e por isso mesmo mais difícil de manter a integridade com o tempo e a evolução do sistema. >CREATE TABLE pedidos ( > idpedido serial PRIMARY KEY, > idcliente integer CONSTRAINT fk_pedido_cliente REFERENCES clientes >(idcliente), > datapedido date default now(), > situacao varchar(1) > ); > >CREATE TABLE peditens ( >idpeditens serial primary key, > idpedido integer CONSTRAINT fk_pedido REFERENCES pedidos (idpedido) ON >DELETE CASCADE, >idproduto integer CONSTRAINT fk_produto REFERENCES produtos >(idproduto), > qtde_item integer default 0 > ); Por exemplo, neste caso cada pedido pode conter infinitos (idpedido, idproduto) iguais. Inconsistência potencial óbvia. >CREATE TABLE pedpecas ( >idpedpecas serial primary key, >idpeditens integer CONSTRAINT fk_peditens REFERENCES peditens >(idpeditens) >ON DELETE CASCADE, > idpecas integer CONSTRAINT fk_pecas REFERENCES pecas (idpecas), > qtde_pecas integer default 0 > ); Analogamente, aqui cada pedpecas pode conter infinitos (peditens, pecas) iguais. Agora compare com o modelo original, onde essas inconsistências, salvo engano meu, são impossíveis: >2015-02-19 21:58 GMT-02:00 Paulo Afonso Pereira < >[email protected]>: > >> CREATE TABLE pedidos ( >> idpedido serial PRIMARY KEY, >> idcliente integer CONSTRAINT fk_pedido_cliente REFERENCES clientes >> (idcliente), >> datapedido date default now(), >> situacao varchar(1) >> ); >> >> CREATE TABLE peditens ( >> idpedido integer CONSTRAINT fk_pedido REFERENCES pedidos (idpedido) >ON >> DELETE CASCADE, >> idproduto integer CONSTRAINT fk_produto REFERENCES produtos >(idproduto), >> qtde_item integer default 0, >> CONSTRAINT pk_peditens PRIMARY KEY (idpedido,idproduto) >> ); >> >> CREATE TABLE pedpecas ( >> idpedido integer CONSTRAINT fk_pedido REFERENCES pedidos (idpedido) >ON >> DELETE CASCADE, >> idproduto integer CONSTRAINT fk_produto REFERENCES peditens >> (idpedido,idproduto) ON DELETE CASCADE, (**AQUI**) >> idpecas integer CONSTRAINT fk_pecas REFERENCES pecas (idpecas), >> qtde_pecas integer default 0, >> CONSTRAINT pk_pedpecas PRIMARY KEY (idpedido,idproduto,idpecas) >> ); Paulo, para facilitar nossa compreensão, você pode dar um exemplo de sessão SQL ilustrando o problema que quer evitar? Obrigado. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:[email protected] +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT−3 MSN: msnim:[email protected] _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
