Em 13-10-2011 13:48, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> 2011/10/13 Shander Lyrio<shan...@nucleo45.com.br>:
>> Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi
>> diversas discursões sobre isto aqui na lista e no final sempre chega-se
>> a conclusão que encontrar uma chave natural que realmente seja única é
>> tão difícil quando encontrar um gnomo no final do arco-íres.
>
> Não é verdade. Quem chega a essa conclusão é quem não entendeu o
> modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as
> conseqüências de sempre para desempenho, documentação, consistência…
Não, quem chega a esta conclusão é quem está vivendo o processo do
desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo
a se encaixar no modelo relacional é contraproducente.
O que seria chave natural para um cadastro de clientes?? cpf se for
física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa
e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento
chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é
o caso de um colega do sul que presta serviço à escolas que se não me
engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes.
Estou quase convencido que não existe uma chave natural perfeita para
este simples cadastro de clientes, que tal um sequenciamento genético?
Hum não funcionaria em empresas!!! Sequenciamento genético com os
donos?? Aeeee!!! E quando a empresa fosse S/A?? Poxa!!!
Você já parou para pensar que quando algo vai para o cache do
PostGreSql, a página de dados toda vai para o cache?? não são
simplesmente os dados, mas toda a página, com todos os campos. Ela pode
inclusive estar cheia de buracos de registros já apagados e atualizados
que ainda não foram recuperados com um vacuum, um campo a mais indo para
o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos
falando do que está definido no effective_cache_size, o assunto é ainda
mais complexo, porque apenas os campos selecionados vão para esta área
da memória para as agregação, join, e etc. Pessoalmente acho que o
melhor custo/benefício é trabalhar com o cache da aplicação, ele bem
administrado vai reduzir drasticamente a quantidade de consultas
enviadas para o banco de dados.
Sempre tem um porém, sempre tem um más. Na prática a teoria é outra
coisa! Ainda acho que o caminho é DBA e equipe de programação tentando
trabalhar juntos, um tentando ajudar o outro no que for melhor para a
aplicação e quando digo aplicação, digo sistema + banco de dados. Se eu
economizo várias horas de programação da equipe eu tenho mais condições
de barganhar um sistema de discos melhor, mais memória, mais processador.
Sei que alguns colegas respondem como se fossem unicamente DBA's a
conversar nesta lista, mas não são, tem caras, onde eu me encaixo, que
estão apenas tentando tornar o gap que existe entre banco de dados e
aplicação um pouquinho menor.
Abraço,
--
Shander Lyrio
http://about.me/shander
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
