Leandro DUTRA escreveu:
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.

  
--- Sei disso. Mas não é o tipo de uso que você esta imaginando.
  
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.

  
--- 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.
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.
  
Usar uma chave artificial te livra de um monte de dor de cabeça
    

Por 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.


  
--- 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.


  
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.


  
--- 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".

  
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.


  
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.


  
--- 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.

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

Responder a