2009/12/29  <[email protected]>:
>> 2009/12/29  <[email protected]>:
>>> ) WITH ( OIDS=TRUE);
>>
>> Evita.
> Porque?

Porque não tem utilidade, engorda a base e ainda possibilita erros de
rpogramação.


>>>    pkbanco serial NOT NULL,
>> Desnecessário, talvez contraproducente.
>  Desnecessário usar PK?

Claro que não.  Desnecessário usar uma chave artificial como primária,
geralmente.  A exceção mais comum a essa regra é quando tem-se uma
chave natural composta de uma tabela pai pequena e (ou) pouco
atualizada, com uma ou mais tabelas filhas grandes e (ou) muito
atualizadas — e, mesmo assim, é bom fazer o perfil de execução para
ver se ainda não será contraproducente.


>>>    uk integer[] NOT NULL,
>>
>> Dá nome significativo.
>
> Definições do projeto, tem significado para nós.

Mas não há razão válida possível para que esse significado não seja
explicitado no modelo.  Até porque UK parece significar "chave única",
o que é uma redundância e genérico demais.


>>>    fkempresa integer NOT NULL,
>>>    fkfilial integer NOT NULL,
>>>    fkunidade integer NOT NULL,
>>
>> Elimina os prefixos.
>>
> Definições de projeto tb, resolvemos usar assim porque facilita a
> escrita e aumenta a produtividade, afinal só vendo o nome do campo sei
> com o que estou trabalhando.

Geralmente isso é contraproducente a médio prazo, porque a base pode
mudar e o que é chave estrangeira deixa de ser, forçando alterações
maiores do que a simples redefinição das restrições de integridade.
Além disso, é pouco legível para quem já não está familiarizado com o
projeto, engorda o código e outras representações, e esconde o fato de
que o mesmo domínio que é chave estrangeira numa tabela não o será
noutras.

As intenções foram boas, mas as decisões não.


-- 
skype:leandro.gfc.dutra?chat      Yahoo!: ymsgr:sendIM?lgcdutra
+55 (11) 3854 7191              gTalk: xmpp:[email protected]
+55 (11) 9406 7191        ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3  MSN: msnim:[email protected]
Sent from Sao Paulo, SP, Brazil
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a