Re: [pgbr-geral] 2 cadastros em uma tabela
Obrigado pelos comentários de vocês. Eu costumo normalizar tudo, e muitas vezes os programadores e outras pessoas que precisam acessar as bases reclamam que precisam "dar mil voltas" pra pegar as informações. Eu mesmo já me peguei reclamando dos meus próprios modelos... hehehe. Por exemplo, costumo ter uma tabela pessoa e outras tabelas para fornecedores, funcionários, etc. No caso dos endereços, que citei no email anterior, sempre há quem reclame que pra pegar o endereço de uma pessoa (em 99,5% dos casos existe apenas um por pessoa) é preciso ir lá na tabela "endereço". Ando tão cansado que nem tenho mais saco pra ficar explicando os motivos. É bom ver alguns comentários reforçando as minhas idéias de vez em quando. :-) 2008/5/15 Leandro DUTRA <[EMAIL PROTECTED]>: > 2008/5/15 Evandro Ricardo Silvestre <[EMAIL PROTECTED]>: > > Se eu condicionar a consultar para apenas *clientes* e tiver um indice > > no campo que indica a categoria da entidade (o campo utilizado para > > condicionar) vai continuar enchendo a memória com os fornecedores? > > Mais um índice, mais escritas, mais leitura, mais uso de cache, mais > complexidade. > > Acredite, normalização foi criada por gente *muito* mais inteligente > do que eu. Não é uma simples técnica, é uma teoria de dependência > funcional muito, muito bem pensada. > > Há exceções? Há, pelo menos com a tecnologia atual. Mas não passa > disso, exceções. Evite otimização precoce, que é a raiz de toda sorte > de males. > > -- > skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra > +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 > +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa Linux User #113925 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 2 cadastros em uma tabela
2008/5/15 Evandro Ricardo Silvestre <[EMAIL PROTECTED]>: > Se eu condicionar a consultar para apenas *clientes* e tiver um indice > no campo que indica a categoria da entidade (o campo utilizado para > condicionar) vai continuar enchendo a memória com os fornecedores? Mais um índice, mais escritas, mais leitura, mais uso de cache, mais complexidade. Acredite, normalização foi criada por gente *muito* mais inteligente do que eu. Não é uma simples técnica, é uma teoria de dependência funcional muito, muito bem pensada. Há exceções? Há, pelo menos com a tecnologia atual. Mas não passa disso, exceções. Evite otimização precoce, que é a raiz de toda sorte de males. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 2 cadastros em uma tabela
2008/5/15 Mozart Hasse <[EMAIL PROTECTED]>: > > Bom, talvez uma segunda opinião te ajude. Muito obrigado, Her Haße! Um resumo magistral, com informações que eu desconhecia. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 2 cadastros em uma tabela
Mozart Hasse wrote: > Alexsander, > > Bom, talvez uma segunda opinião te ajude. > Comentários abaixo. > > >> From: "Alexsander Rosa" <[EMAIL PROTECTED]> >> Subject: Re: [pgbr-geral] 2 cadastros em uma tabela >> To: "Comunidade PostgreSQL Brasileira" >> >> O que é uma tabela "cheia de NULLs"? Ter 3 ou 4 colunas com 90% dos >> > valores > >> NULL numa tabela com 30 colunas é estar "cheio de NULLs"? >> > > 90%?! Com certeza! "Cheio" é pouco, eu diria *entupido* de NULLs. Qualquer > índice sobre um campo assim será quase sempre ignorado pelo otimizador. > Logo, toda a vez que você quiser consultar só os clientes, o servidor vai > trazer para a memória os fornecedores também, só para despediçar CPU e > disco ignorando-os. Se eu condicionar a consultar para apenas *clientes* e tiver um indice no campo que indica a categoria da entidade (o campo utilizado para condicionar) vai continuar enchendo a memória com os fornecedores? Evandro ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] 2 cadastros em uma tabela
Alexsander, Bom, talvez uma segunda opinião te ajude. Comentários abaixo. > From: "Alexsander Rosa" <[EMAIL PROTECTED]> > Subject: Re: [pgbr-geral] 2 cadastros em uma tabela > To: "Comunidade PostgreSQL Brasileira" > > O que é uma tabela "cheia de NULLs"? Ter 3 ou 4 colunas com 90% dos valores > NULL numa tabela com 30 colunas é estar "cheio de NULLs"? 90%?! Com certeza! "Cheio" é pouco, eu diria *entupido* de NULLs. Qualquer índice sobre um campo assim será quase sempre ignorado pelo otimizador. Logo, toda a vez que você quiser consultar só os clientes, o servidor vai trazer para a memória os fornecedores também, só para despediçar CPU e disco ignorando-os. Não, um índice condicional não vai ajudar grande coisa, a não ser que você duplique *todos* os índices sobre os outros campos, fazendo um só com os clientes e outro só com os fornecedores para cada um deles. Mesmo que você me convença que isso não complica seu gerenciamento da base nem detona significativamente seu desempenho para gravações, com certeza é muito mais complicado do que manter índices simples (sem condições) sobre cada uma das tabelas "filhas", que com certeza seriam usados com muito maior frequência que seus equivalentes na tabela unificada. > O que é melhor, > desperdiçar alguns bytes ou ter que fazer um monte de JOINs pra fazer > qualquer consulta simples? Contando espaço alocado pelos índices de qualquer aplicação grande, você vai economizar espaço normalizando corretamente essa tabela ao invés de misturar tudo num "tabelão" "gordo". > Nessa mesma linha, cabe outra pergunta: o que é > uma tabela "muito mais gorda"? É uma tabela com qualquer uma das seguintes características: 1. Uma tabela com muito mais registros do que os frequentemente acessados por cada consulta. 2. Uma tabela com muito mais campos do que os frequentemente buscados pelas consultas mais usadas. 3. Uma tabela com muito mais acessos a disco do que o necessário. 4. Uma tabela com redundâncias por estar mal normalizada. > Um outro exemplo: o endereço. Se uma "pessoa" (de qualquer tipo) pode ter > mais de um endereço, seria o caso de criar uma tabela "endereço" separada > com um relacionamento 1:N de modo de uma pessoa possa ter mais de um > endereço. O problema é que em 99,5% dos casos (acabei de conferir aqui pois > tenho um sistema modelado assim) o cliente tem apenas um endereço > cadastrado. Será que todo o trabalho necessário para buscar o endereço > compensa? 1. Se você precisar tratar decentemente esse relacionamento 1:N, o trabalho que as tabelas normalizadas dão é menor. 2. Se está pensando no esforço que o servidor terá buscando os dados, consulte o EXPLAIN nos dois casos e note que para qualquer caso não trivial é bem mais rápido e eficiente buscar os dados em tabelas normalizadas. > Não seria mais fácil ter campos de endereço na própria tabela > "pessoa" e usar a tabela "endereço" apenas para os endereços alternativos? É > uma pergunta que já me fizeram várias vezes. Não, não seria mais fácil nem para o programador, muito menos para o otimizador. > > Se for um sistema muito pequeno, dá para administrar. Mas sempre será > > muito mais dor de cabeça que o necessário, e mais lento também. Sim, eis porque não há motivo para trabalhar com dados não normalizados em tabelas grandes. > O que é um sistema "muito pequeno"? Com até 100.000 registros na tabela > "pessoa"? Bom, com esse volume já dá para medir diferenças de desempenho entre as duas abordagens. Se tua tabela de pessoas servir para mais do que imprimir etiquetinhas de mala direta, faça um teste realista e veja a diferença. Atenciosamente, Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] como usar Heap Only Tuples (HOT)
Mr J.L. wrote: > Dei uma olhada nas novidades do postgresql, mas nao entendi direito algo > referente ao "Heap Only Tuples (HOT)". > Isso eu teria que implementar na hora de criar um indice, ou coisa > parecida? ou implicitamente os indices na versao 8.3 ja tem essa > caracteristica? > Você não precisa configurar nada para utilizar o HOT [1]; ele é uma implementação interna. O que é o HOT? É uma técnica que elimina entradas redundantes no índice e permite o reuso do espaço anteriormente ocupado por tuplas atualizadas (UPDATE) ou removidas (DELETE). O que isso significa? (i) executar menos o VACUUM (ii) reduzir o espaço utilizado. A principal vantagem do HOT vem quando você atualiza um dado que não está indexado pois assim você não precisa criar nova entrada no índice para aquela tupla. Testes realizados mostraram um ganho significativo de performance após a sua implementação [2]. [1] http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/heap/README.HOT [2] http://www.kaltenbrunner.cc/blog/index.php?/archives/21-8.3-vs.-8.2-a-simple-benchmark.html -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] SCHEMA HSQLDB
2008/5/15 Euler Taveira de Oliveira <[EMAIL PROTECTED]>: > Leandro DUTRA wrote: > >> Euler, só se você for purista no conceito de 'embutido', sendo que >> nesse campo não cabe purismo. >> > No meu ponto de vista (e de muitos outros pesquisadores da área), > embutido (aka embedded) está relacionado a arquitetura do SGBD. Correto! Mas a questão aqui é sobre _uso_, e isso o PostgreSQL atende muito bem, melhor que muitos sistemas arquitetonicamente embutidos. Certo? -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] como usar Heap Only Tuples (HOT)
Pessoal, Dei uma olhada nas novidades do postgresql, mas nao entendi direito algo referente ao "Heap Only Tuples (HOT)". Isso eu teria que implementar na hora de criar um indice, ou coisa parecida? ou implicitamente os indices na versao 8.3 ja tem essa caracteristica? Caso tenha que implementar algo, como seria essa implementacao? Obrigado. Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] SCHEMA HSQLDB
Leandro DUTRA wrote: > Euler, só se você for purista no conceito de 'embutido', sendo que > nesse campo não cabe purismo. > No meu ponto de vista (e de muitos outros pesquisadores da área), embutido (aka embedded) está relacionado a arquitetura do SGBD. Embutido quer dizer acoplado, ou seja, os dados e a camada de acesso aos dados está acoplada a aplicação (na mesma máquina física ou lógica -- compartilhamento). É sabido que o PostgreSQL não trabalha assim. Com uma arquitetura mais robusta para desacoplar as camadas e conseguir uma boa escalabilidade no acesso concorrente aos dados -- esse é um dos pontos fracos da arquitetura embutida. -- Euler Taveira de Oliveira http://www.timbira.com/ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] RES: Quero sair da lista.......
Cristiano Martins Ribeiro (Informatica) escreveu: > Aproveito o assunto para repetir o aviso: já executei o procedimento descrito > pelo Sr. Aluisio, várias vezes, em diferentes datas, e não consegui retirar o > meu e-mail da lista. > > Gostaria de ser retirado também. > > Obrigado. > Cristiano Martins > > > -Mensagem original- > De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Aluisio Gouveia > Enviada em: quarta-feira, 14 de maio de 2008 15:59 > Para: Comunidade PostgreSQL Brasileira > Assunto: Re: [pgbr-geral] Quero sair da lista... > > Carlos B. Schmidt escreveu: > >> Não consigo sair da lista do grupo, alguém por favor pode cancelar >> >> Clicando no botão /Unsubscribe/, *uma mensagem de confirmação será reenviada a você por email*. Esta mensagem terá um link que deverá clicar para completar o processo de remoção (você poderá também confirmar por email; veja as inscrições na mensagem de confirmação). OBS: antes de clicar no desinscrever vc tem que efetuar login -- Esta mensagem foi verificada pelo sistema de Anti-virus da SJB Solados. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] RES: Quero sair da lista.......
Aproveito o assunto para repetir o aviso: já executei o procedimento descrito pelo Sr. Aluisio, várias vezes, em diferentes datas, e não consegui retirar o meu e-mail da lista. Gostaria de ser retirado também. Obrigado. Cristiano Martins -Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Aluisio Gouveia Enviada em: quarta-feira, 14 de maio de 2008 15:59 Para: Comunidade PostgreSQL Brasileira Assunto: Re: [pgbr-geral] Quero sair da lista... Carlos B. Schmidt escreveu: > Não consigo sair da lista do grupo, alguém por favor pode cancelar > > > ___ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > Acesse https://listas.postgresql.org.br/cgi-bin/mailman/options/pgbr-geral, preencha o campo email e clique em DESINSCREVER -- Cordialmente; Aluisio Gouveia ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] SCHEMA HSQLDB
2008/5/14 Euler Taveira de Oliveira <[EMAIL PROTECTED]>: > Leandro DUTRA wrote: > >> Use o PostgreSQL embutido. >> > O PostgreSQL *não* trabalha/trabalhará de modo embutido (ele não é uma > biblioteca de acesso a dados). Existem outros "SGBDs" tais como SQLite e > Apache Derby (aka JavaDB) que trabalham nesse modo, mas *não* o > PostgreSQL. Euler, só se você for purista no conceito de 'embutido', sendo que nesse campo não cabe purismo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [OFF] SCHEMA HSQLDB
2008/5/14 Daniel Gaspary <[EMAIL PROTECTED]>: > On Wed, May 14, 2008 at 11:20 AM, Leandro DUTRA > <[EMAIL PROTECTED]> wrote: >> >> Use o PostgreSQL embutido. > > Já usou na prática de algum projeto o PG assim ? Sim, toda vez que usei Mac OS X! > É que até no FAQ do PG é desaconselhado esse tipo de uso. Não é bem assim: http://www.postgresql.org/docs/faqs.FAQ.html#item1.13 > Todo caso, se usou seria interessante se pudesse descrever as > modificações que teve de fazer. Se foi simples ou não. Ambiente (O.S.) > , performance etc Não constam problemas de desempenho no Rendezvous. Não é preciso modificações; basta criar uma base local do usuário no primeiro uso. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3040 7300 r155 gTalk: xmpp:[EMAIL PROTECTED] +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 +55 (11) 5685 2219 MSN: msnim:[EMAIL PROTECTED] ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
