2015-02-20 10:34 GMT-02:00 Leandro Guimarães Faria Corcete DUTRA < l...@dutras.org>:
> Le 19 février 2015 22:27:07 GMT-02:00, Everton Berz < > everton.b...@gmail.com> a écrit : > >Sua modelagem está confusa. > > Em quê? > > Principalmente nas FK's que eu e o resto do pessoal já citou. > > >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. > Sim, ele só usou chaves artificiais, mas não da maneira típica de criar PK's pra cada uma. > > > >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. > > Desculpe, só estou seguindo o que muitas literaturas dizem. O teu "fica mais difícil de entender" pra uns é diferente pra outros. Onde fica mais difícil de manter a integridade? Cite exemplos e provas. Não precisa, essa discussão iria muito longe e teríamos que abrir outra thread. "Some people will tell you that you should always use natural keys and others will tell you that you should always use surrogate keys. These people invariably prove to be wrong, typically they're doing little more than sharing the prejudices of their "data religion" with you. The reality is that natural and surrogate keys each have their advantages and disadvantages, and that no strategy is perfect for all situations. In other words, you need to know what you're doing if you want to get it right." -- http://www.agiledata.org/essays/keys.html > > >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: > > Isso resolveria facilmente criando uma unique key, ou eu esqueci ou só quis deixar para o OP entender sozinho isso. > >2015-02-19 21:58 GMT-02:00 Paulo Afonso Pereira < > >pa...@visualpsistemas.com.br>: > > > >> 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:leand...@jabber.org > +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 > BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
