Jocimar de Oliveira escreveu: > On Friday 27 June 2008 17:00:08 Leandro DUTRA wrote: >> 2008/6/27 Jocimar de Oliveira <[EMAIL PROTECTED]>: >>>> E isso numa base que gira em torno de 150 GB tem muita diferença. >>> Matando curiosidade: 150 GB de cadastro de clientes PF + PJ ? >> Creio que ele está se referindo a uma base relativamente grande, onde >> a organização e a centralização podem fazer muita diferença, tanto em >> desempenho quando em gestão de segurança, entre outras coisas. > > Esta questão eu entendi, tanto que questionei sobre o tamanho que ocupa > os dados de cadastro de clientes PF + PJ, e só foi por curiosidade, > pois fiquei imaginando o tamanho do banco de dados inteiro.
Era o banco inteiro Jocimar. > (...) > Nos trabalhos que venho ajustando meu sistema atual, havia em torno de > 140 tabelas, e fazendo vários ajustes para iniciar esta migração já > passei das 200 tabelas, mas no meu caso o perfil de meus clientes não > há necessidade de normatizar mais o cadastro de clientes, separando PF > e PJ. No caso o seu cadastro de PJ e PF pode não ser grande o suficiente para gerar problemas de desempenho, mas já vi casos (um deles foi com bens, veiculos e imoveis de pessoas tudo numa tabela só) que degradavam consideravelmente a performance do banco, que por sua vez era consequencia de indices ineficientes em campos com muitos valores nulos e forte acoplamento de dados com alguns campos tornando-os responsaveis por mais de uma informação ao mesmo tempo. Dai surgiu a minha colocação. Mas em minha opnião tomamos decisões baseadas em niveis de risco, que por sua vez são particulares a cada situação. Essas particularidades nos levam a escolher padrões pré-definidos a fim de não re-inventemos a roda ao mesmo tempo que tentamos lidar com exceções baseando-se no histórico de nossas próprias experiências. Em tempo, o conteúdo dessa lista é publico e pode ser consultado por outros usuários mesmo que não participem da lista, de forma que nossas palavras aqui perpetuam por muito e muito tempo, e este em particular pode ser um motivo pelo qual alguns respondem uma pergunta pensando no histórico da lista com uma posição firme, tendo em vista que existe o lado profissional envolvido que fica exposto, não só aqui como em outras listas. -- []s Dickson S. Guedes ------------------------------------- Projeto Colmeia - Curitiba - PR (41) 3254-7130 ramal: 27 http://pgcon.postgresql.org.br http://makeall.wordpress.com/ http://planeta.postgresql.org.br/ _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
