2008/7/9 Leandro Guimaraens Faria Corcete DUTRA <[EMAIL PROTECTED] >:
> Le mercredi 09 juillet 2008 à 17:20 -0300, Rudinei Dias a écrit : > > > mas o caso que me refiro, por exemplo, era um tipo de log que > > registrava todas as alterações de uma tabela de débitos. > > Jah pensou se alguem mexe no programa e vai duplicando os registros no > log? Aas vezes mesmo uma chave que seja todos os atributos da tabela, > ou um TIMESTAMP, eh melhor que nada. Leandro, sem querer criar polêmica, mas já que foi criada... Como eu disse, e repito, cadas caso é um caso. *Você tem razão por questões de projeto*, se pudesse ser alterado o programa. A solução aplicada não é a adequada para um projeto novo ou algo que possa ser remodelado. Mas no caso (*BEM específico*): - Não havia a possibilidade de alteração do programa; - Qualquer alteração efetuada na base não poderia impactar na performance; - Mudar um campo DATE para TIMESTAMP influenciaria diretamente no programa; - Adicionar um novo campo timestamp dá no mesmo que adicionar qualquer outro campop na tabela - mas, nesse caso *BEM específico*, criar uma chave natural com 6 colunas na chave influenciaria com certeza na performance. então a solução para esse caso *BEM específico*, cuja regras haviam definidas, em que nada deveria impactar no resultado final. E, por fim, *e isso é meu ponto de vista pessoal*, colocar chave primária com muitos campos (mais de um) em logs é uma coisa a se pensar, até evitar, visto que logs crescem numa velocidade espantosa, não são parte do processo do negócio e sim parte do processo de controladoria, que deve existir mas não deve impactar no sistema. Leandro, não quero criar polêmica, só expressar meu ponto de vista. Considero isso uma discussão muito válida até para aprimorar filosofias de trabalho e criar alternativas. Um grande abraço. Rudinei.
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
