2011/10/13 Shander Lyrio <[email protected]>: > > 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.
Modelo não é e nunca foi explicação, é formalização. Se não pode ser formalizado, será inconsistente. > 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. > 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. > 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. > 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í? > 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. > 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. E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não ser o DBA. > 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. > 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. _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
