> 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. > -- Não é o nosso caso, usamos os OIDS para algumas coisas internas como posicionamento de cursores, melhor que criar uma estrutura só para controlar isso. > >>>>   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. > -- Geralmente não é regra, pelo menos sempre li que é para evitar chaves naturais como pk. Usar uma chave artificial te livra de um monte de dor de cabeça na minha opinião.
>>>>   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. > -- Bah daí concordo contigo! O nome poderia ser outro, mas essa é uma daquelas coisas que acabam ficando pra trás, no nosso caso é uma UK tanto no nome como na função hehe! >>>>   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. -- Bom daí já discordo um pouco. Pra mim base e modelo que precisam ser alterados no meio do caminho é igual a sistema mal feito e mal projetado. Mas isso é claro é a minha opinião. > As intenções foram boas, mas as decisões não. -- Até agora estão se mostrando excelentes, tomara que continuem assim. As vezes a teoria é uma coisa, mas na prática é outra! Abração, Fabiano > > -- > 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 > _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
