Em 13-10-2011 15:44, Guimarães Faria Corcete DUTRA, Leandro escreveu:
> 2011/10/13 Shander Lyrio<[email protected]>:
>> 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.
>
> Sim, e a conclusão sempre foi a mesma: em última instância, a chave
> natural pode vir a ser a tabela toda, excluídos atributos artificiais.
> Se nem isso identificar, então a base de dados será inconsistente.
Certo, num cadastro de clientes deveríamos colocar todos os campos como
chave primária. É esta sua opinião? Porque se for, ela contraria as suas
colocações anteriores de que se a chave fosse natural estaria em
memória, seria mais rápido fazer consultas, etc, etc, etc..
>> 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!!!
>
> Quem perde a calma perde a razão.
Não perdi a calma não, eu estou escrevendo este e-mail até rindo. Acho
engraçado você defender tanto a teoria quando não consegue pela teoria
se justificar com um fato real simples como esse.
>> Você já parou para pensar que quando algo vai para o cache do
>> PostGreSql, a página de dados toda vai para o cache??
>
> Por favor, o nome do sistema é PostgreSQL ou Postgres.
Você vive de teoria de banco de dados, um monte de falácia que quando
confrontada com a realidade, não consegue se sustentar. Você sequer
conseguiu explicar como ter uma chave natural fiável num simples
cadastro de clientes, e tenta mudar o assunto chamando atenção para a
forma que eu coloco a caixa alta ou baixa no meu texto?
>> 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.
>
> E daí?
E daí que seu argumento de cache sujo por causa de uma chave artificial
cai por terra, porque ele é muito mais do que sujo, antes mesmo de a
chave artificial existir. Ou seja, o fato de a chave artificial sujar o
cache é absolutamente irrelevante.
>> 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.
>
> O seu achômetro pessoal vai contra a experiência geral da humanidade.
> O cache da aplicação tem seu lugar, mas ele não está tão próximo do
> disco quanto o da base.
Você *acha* que a experiência geral da humanidade é esta. Eu estou
falando de custo/benefício e não qual cache é melhor. O que você pode
fazer de efetivo para melhorar o desempenho da aplicação com relação ao
cache do banco de dados?? Nada ou bem próximo disso!! Aumentar o cache
pode ser feito com ou sem ORM, então nem conta. Trabalhando em um cache
de aplicação eu posso ser muito mais efetivo porque vou criar um ganho
real para a aplicação e alivar a quantidade de consultas ao banco de
dados, independente do ganho que o cache de banco de dados já me
proporciona.
Entendeu agora?? custo/benefício. Com relação ao cache de banco nada
pode ser feito senão aumentar ou diminuir ele, na aplicação muito pode
ser feito, por isso insisto no tema. Trabalhar junto! Desenvolvimento +
Banco de dados para o sucesso do conjunto!!
> E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não
> ser o DBA.
Suas respostas estão sendo dadas como DBA ou como AD? De qualquer forma
acredito que você esteja vendo a situação apenas de um ângulo.
>> 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.
>
> O que não adianta nada quando a aplicação não escala e a base é inconsistente.
Na prática a teoria é outra. Os bancos de dados mais escaláveis não tem
nada de consistentes, nada de primary keys ou foreign keys, restrição de
campos, unique, rigidez de estrutura das tabelas, etc. Vide vários noSql
que estão por aí ganhando terreno onde escalabilidade é o fator
importante. Na prática, um certo nível de inconsistência desde que
controlado é facilmente absorvido.
>> 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.
>
> E esses caras fariam bem em tentar aprender um pouco em vez de sempre
> reagir emocionalmente.
Não estou emocional apesar de você insistir muito neste assunto.
Acontece que suas respostas são bonitas teoricamente mas a maioria delas
não se aplica à prática. Eu estou mostrando isto com diversos argumentos
e acho que você não está gostando. Na falta do que responder, diz que eu
estou sendo emocional.
--
Shander Lyrio
http://about.me/shander
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
