Leandro DUTRA escreveu:
--- Sei disso. Mas não é o tipo de uso que você esta imaginando.2009/12/29 <fabi...@wolaksistemas.com.br>:2009/12/29 <fabi...@wolaksistemas.com.br>:2009/12/29  <lis...@softpira.com>:) WITH ( OIDS=TRUE);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.Pelo contrário… OIDs podem alterarem-se com restauração de cópias de segurança, podem ciclar… melhor criar algo que esteja no modelo, se for uma necessidade real. OIDs são resquício da tentativa (fracassada) de se fazer um SGBD SQL-OO. --- Não evita duplicidade? Me de um exemplo ou um case por favor, porque então a documentação está errada e tudo o que li tb.sempre li que é para evitar chaves naturais como pk.Por quê? Pelo contrário, uma chave artificial não evita duplicidade, engorda a base e dificulta o entendimento do modelo. Uma chave natural por exemplo CPF, nada te garante que no futuro não irá mudar o padrão e ali o teu modelo foi pro saco. --- Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que o banco trabalha. Obscurece o modelo? Por favor seja mais específico.Usar uma chave artificial te livra de um monte de dor de cabeçaPor exemplo? Pelo contrário, usar chaves artificiais, a médio prazo, gera muita dor de cabeça porque engorda a base (geralmente) e obscurece o modelo (sempre). Muitas vezes, nem se definem boas chaves naturais porque se usou o quebra-galho da artificial. --- Como hj estamos envolvidos com outros módulos do sistema já não vale a pena ficar mudando apenas para ficar "bonito e no padrão".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!O tipo da alteração que pode valer a pena, embora possa ser meio traumática. 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.A curto prazo, sim. A longo, não. --- Essa afirmação é bem contundente, mas como esse sistema já está a 3 anos rodando no primeiro cliente (indústria com faturamento médio de 5 milhões mensais) acredito que já estamos no meio do caminho e se o modelo se mostrou eficiente até agora, duvido que vou ter problemas daqui pra frente, de qualquer forma vou guardar esse email e daqui a alguns anos tiramos a prova.Até agora estão se mostrando excelentes, tomara que continuem assim. As vezes a teoria é uma coisa, mas na prática é outra!Não vão continuar, são típicas decisões sem fundamento teórico nem, a longo prazo, prático. Regras criadas por desenvolvedores que nem entendiam dados, nem tiveram de dar manutenção em sistemas evoluídos ao longo do tempo. Algumas até generalizações incorretas de situações específicas. Citando um trecho de uma palestra do Telles: "- Uma pessoa sem bom senso não se preocupa com melhores práticas - Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas - Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas" Abração, Fabiano Machado Dias |
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral