Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Fernando, apenas para não existir erros de interpretação, pois relendo agora a frase eu mesmo demorei a compreender o que escrevi. Faltou pontuação na mesma... rss Com a pontuação adequada ficaria: Concordo com o que o Euler colocou sobre a quantidade excessiva de índices. Uma vez que o SGBD não utiliza mais de um índice por pesquisa, são extremos os casos onde há a necessidade de mais de 5 índices por tabela. []'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/3 Fernando Maia maia...@gmail.com Olá pessoal, eu achu que essa frase responde minha duvida! Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. não é mesmo! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
OLá Charly, Me corrija se estiver errado, de acordo com o que você escreveu não importa se eu tenho 1 ou 50 indices em uma tabela, pois quando faço uma consulta ao banco o SGBD utiliza muito poucos indices para realiza-la. certo? abraços, obrigado pela ajuda. 2009/10/5 Charly Frankl carl...@gmail.com Fernando, apenas para não existir erros de interpretação, pois relendo agora a frase eu mesmo demorei a compreender o que escrevi. Faltou pontuação na mesma... rss Com a pontuação adequada ficaria: Concordo com o que o Euler colocou sobre a quantidade excessiva de índices. Uma vez que o SGBD não utiliza mais de um índice por pesquisa, são extremos os casos onde há a necessidade de mais de 5 índices por tabela. []'s -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/3 Fernando Maia maia...@gmail.com Olá pessoal, eu achu que essa frase responde minha duvida! Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. não é mesmo! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
Charly Frankl escreveu: Resumindo, a cada consulta o SGBD elege APENAS UM índice da entidade para ser utilizado na consulta. É claro que não. O SGBD pode escolher quantos índices quiser; isso vai depender da consulta que você está executando. -- 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] Aumentar Número de Indices por Tabe la
2009/10/5 Euler Taveira de Oliveira eu...@timbira.com É claro que não. O SGBD pode escolher quantos índices quiser; isso vai depender da consulta que você está executando. Mas isso é válido se o enable_bitmapscan estiver habilitado, porque se estiver desligado o planejador vai usar (ou não) um índices por tabela... certo??? (dúvidas) [1] http://www.postgresql.org/docs/8.4/interactive/indexes-bitmap-scans.html -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] Aumentar Número de Indices por Tabe la
Fabrízio de Royes Mello escreveu: 2009/10/5 Euler Taveira de Oliveira eu...@timbira.com mailto:eu...@timbira.com É claro que não. O SGBD pode escolher quantos índices quiser; isso vai depender da consulta que você está executando. Mas isso é válido se o enable_bitmapscan estiver habilitado, porque se estiver desligado o planejador vai usar (ou não) um índices por tabela... certo??? (dúvidas) Como eu disse anteriormente, o planejador pode produzir um plano que utiliza mais do que um índice por tabela. Por exemplo, em junções com a mesma tabela e quando a tabela aparece em mais de um nó no plano de execução. -- 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] Aumentar Número de Indices por Tabe la
2009/10/5 Euler Taveira de Oliveira eu...@timbira.com Como eu disse anteriormente, o planejador pode produzir um plano que utiliza mais do que um índice por tabela. Por exemplo, em junções com a mesma tabela e quando a tabela aparece em mais de um nó no plano de execução. Tranquilo... isso eu sabia... mas no mesmo nó somente com o bitmapscan para utilizar mais de um índice né? -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.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] Aumentar Número de Indices por Tabe la
Charly, É por ai mesmo. Na verdade, você pode ter os 50 índices na tua tabela, mas quando for consultá-la o SGBD vai eleger UM índice a ser utilizado para a consulta. Logo, ter 50 índices não é garantia de melhoria na performance da pesquisa, mas alguns índices bem planejados vão com certeza ajudar. Resumindo, a cada consulta o SGBD elege APENAS UM índice da entidade para ser utilizado na consulta. Contra-exemplo trivial: --Cidades do Acre com homônimos em outro estado: select distinct c2.nomecidade from tbcidade c2 inner join tbcidade c on c.nomecidade = c2.nomecidade and c.ufc2.uf where c2.uf='AC' Esta consulta me gerou o seguinte plano: HashAggregate (cost=106.66..106.88 rows=22 width=13) - Nested Loop (cost=2.43..106.60 rows=26 width=13) Join Filter: ((c.uf)::text (c2.uf)::text) - Bitmap Heap Scan on tbcidade c2 (cost=2.43..28.09 rows=23 width=16) Recheck Cond: ((uf)::text = 'AC'::text) - Bitmap Index Scan on i1tbcidade (cost=0.00..2.42 rows=23 width=0) Index Cond: ((uf)::text = 'AC'::text) - Index Scan using a1tbcidade on tbcidade c (cost=0.00..3.40 rows=1 width=16) Index Cond: ((c.nomecidade)::text = (c2.nomecidade)::text) E olha que nem precisei apelar para mais de uma tabela, UNIONs, EXISTS, filtros com OR ou sub-selects! Como pode ver, o otimizador notou, pela distribuição dos dados, que compensa usar um índice diferente para cada citação da tabela dentro da mesma consulta (i1tbcidade e a1tbcidade). Não sei se só eu noto isso, mas a maioria das querys com sub-selects ou cláusulas EXISTS que observei na minha aplicação usam índices diferentes para a mesma tabela. Logo, no meu caso, ter um monte de índices na mesma tabela compensa sim, e muito. 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] Aumentar Número de Indices por Tabe la
De fato, nas versões apartir da 8.2 (se nao me engano) o postgresql consegue simular um indice bitmap em memória, mas como disposto também em [1]: A condição pode ser dividida em n utilizações separadas de um índice sobre uma condição where. Depois é verificado o operador. Depois de os resultados serem recuperados são juntados usando o operador. Para combinar os índices compostos, o sistema percorre cada índice necessário e cria um bitmap em memória, que fornece a localização das tuplas que verificam as condições dos índices. Os bitmaps são então unidos (tendo em conta a interrogação, usando ANDs ou ORs) e as tuplas reais são devolvidas. As tuplas são então visitadas pela ordem física que apresentam, por essa ser a ordem representada pelos bitmap, o que significa que qualquer ordenação do índice original é perdida, e que um passo extra de ordenação irá ser necessário no caso da interrogação incluir uma cláusula ORDER BY. Por esta razão e por ser necessário percorrer o índice um maior número de vezes, o otimizador em geral opta por utilizar um índice simples mesmo tendo outros índices disponíveis. Algumas boas literaturas que podem ser vista sobre o tema são: SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de Dados. Editora Makron Books. MOLINA, Hector Garcia; ULLMAN, Jeffrey D.; WIDOM, Jennifer. Database Systems – The complete book. Prentice Hall NAVATHE; ELMASRI. Sistema de Banco de Dados: Fundamentos e Aplicações. Editora LTC [1] http://www.postgresql.org/docs/8.4/static/indexes-bitmap-scans.html Att, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/5 Fabrízio de Royes Mello fabriziome...@gmail.com 2009/10/5 Euler Taveira de Oliveira eu...@timbira.com Como eu disse anteriormente, o planejador pode produzir um plano que utiliza mais do que um índice por tabela. Por exemplo, em junções com a mesma tabela e quando a tabela aparece em mais de um nó no plano de execução. Tranquilo... isso eu sabia... mas no mesmo nó somente com o bitmapscan para utilizar mais de um índice né? -- Fabrízio de Royes Mello Blog sobre TI: http://fabriziomello.blogspot.com ___ 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] Aumentar Número de Indices por Tabe la
Fabrízio de Royes Mello escreveu: Tranquilo... isso eu sabia... mas no mesmo nó somente com o bitmapscan para utilizar mais de um índice né? Não, com os algoritmos de junção podemos ter buscas em vários índices simultaneamente também. -- 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] Aumentar Número de Indices por Tabe la
Mozart, boa tarde... Acho que não entendeu bem quando eu usei o termo apenas um índice por tabela. Como pode ver, o otimizador notou, pela distribuição dos dados, que compensa usar um índice diferente para cada citação da tabela dentro da mesma consulta (i1tbcidade e a1tbcidade). Como você mesmo colocou, o otimizador optou por usar um índice diferente para *cada citação da tabela* dentro da mesma consulta. Logo, percebe-se que o otimizador trata a mesma entidade como entidades diferente (c e c1). Se você observar, ele optou apenas por um índice para cada entidade sendo: - Index Scan using a1tbcidade on tbcidade c - Bitmap Heap Scan on tbcidade c2 (cost=2.43..28.09 rows=23 width=16) - Bitmap Index Scan on i1tbcidade ou seja, - a1tbcidade para tbcidade c - i1tbcidade para tbcidade c2 Note a diferença nos usos. Não sei se só eu noto isso, mas a maioria das querys com sub-selects ou cláusulas EXISTS que observei na minha aplicação usam índices diferentes para a mesma tabela. Segue aqui o mesmo conceito definido anteriormente. Quando você utiliza uma subconsulta, o otimizador trata de fato como um novo uso para a entidade. Logo, ele pode eleger um índice diferente na consulta interna (tb1) diferente do eleito pra consulta externa (tb1-a ). Logo, no meu caso, ter um monte de índices na mesma tabela compensa sim, e muito. Não creio ser esse o tema do debate, se no teu caso compensa ou não. Mesmo porque, ninguém aqui alem de você pode julgar isso. Agora, voltando ao tema de muitos índices por tabela, como exposto anteriormente pelos colegas Euler e Fabrízio, o PostgreSQL consegue nas novas implementações simular índices bitmap (com seus custos, mas consegue). Inclusive no exemplo que enviou podemos observar o PostgreSQL fazendo uso do recurso, e percebe-se notadamente o que foi exposto na documentação: Recheck Cond: ((uf)::text = 'AC'::text). Agora, com relação a expressão Não sei se só eu noto isso..., desculpe-me se em algum momento meus posts pareceram ser pessoais, muito pelo contrário, apenas tentei colaborar com o debate, mesmo porque é um tema muito interessante. E como falei, todos temos o direito de discordar, errar e acertar dentro dos nossos debates, é isso que torna esta lista construtiva, os erros e acertos de cada um! Um grande abraço, -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Andre Fernandes, Antes de mais nada, sr. Mozart, peço que o tom nestas mensagens que tens enviado seja menos agressivo. Sr. Andre, o tom dos meus comentários está compatível com o dos meus críticos. Quanto a ter mais de 10 registros, isso para um banco de dados não é muita coisa. Olhando o contexto da citação, notará que o objetivo era dar ao interlocutor uma chance de dar uma opinião minimamente informada, e não fazer comparações com outras aplicações. Não conheço teu aplicativo para dizer se realmente há algo de errado ou não, assim não entrarei nesse mérito. Ótimo, aguardo para ver se os que entraram nesse mérito vão chegar a essa mesma conclusão ou nos surpreender ensinando-nos alguma coisa com uma resposta tecnicamente justificável. Imagino que ... Eu também imagino um monte de coisas. Quando tiver algo concreto me avise. E quanto ao sr. Euler, ele é uma das pessoas que mais conhece postgreSQL no Brasil, não menospreze ... Ninguém aqui citou cargos, títulos, popularidade ou autoridade até o momento porque isso nunca foi nem nunca será motivo para definir quem tem razão. Por favor, atenha-se aos argumentos pertinentes ao assunto. 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] Aumentar Número de Indices por Tabe la
Tarcísio, 1 para escrever no log. 32 outros arquivos sendo um para cada índice. 1 para a tabela. Isso o Euler já explicou, leia com atenção minha mensagem sobre essa conta para entender o que eu questionei. Mozart, a única *coisa estranha* que *eu* vejo é a necessidade de usar 44 índices. Provavelmente você está criando um para cada coluna. Parece estranho e mesmo assim não deixa de ser muito útil. Não, não estou criando um por coluna. Você mesmo disse: ... eu quase sempre uso todos os 89 campos ... Então crie 1 índice contendo todas as colunas que fazem referência às dimensões. Eu expliquei na mesma mensagem o que eu tenho contra essa idéia. Recomendo que crie uma tabela com vários campos, chaves estrangeiras e um índice com todos os campos, depois tente achar uma consulta em que esse índice sirva para alguma coisa além de ocupar espaço. Com 89 campos e 10 registros acho pouco provável que consiga. Mesmo que você faça uma consulta que não utilize estas colunas no filtro, a consulta ainda poderá usar o índice parcialmente. Por enquanto estou usando só índices que usem as colunas no filtro, por isso estou com apenas 44. Se eu resolver incluir índices que não usem aí o número vai aumentar, e não diminuir. Não crie também índices malucos como exemplo: 1 índice para cd_cliente, outro para cd_produto e outro para as duas colunas: cd_cliente e cd_produto. Apenas crie 1 índice para as 2 colunas. Não tem nada de maluco em criar todos eles ao mesmo tempo. Isso até seria pertinente a algumas situações específicas de algumas versões do Oracle, porém no Postgres não se aplica. Tenho diversas tabelas e consultas em que o otimizador algumas vezes escolhe os índices individuais e em outras os índices com as colunas agrupadas. Por acaso ter o índice usado em alguma consulta é suficiente para esse índice não ser chamado de maluco ou é preciso algo mais? Alguma justificativa a expor? Novamente eu recomendo para você o livro: http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704 Um livro sobre modelagem de *datawarehouse* ?! Eu já expliquei em mensagens anteriores que o meu caso nem é um datawarehouse, mas vamos lá: tem algum trecho desse livro que você possa citar para justificar as recomendações sobre índices que está sugerindo? 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] Aumentar Número de Indices por Tabe la
Euler, Você *não* mostrou essa tal tabela, os índices dela e, o mais importante, as estatísticas de uso desses índices. (...) Ugh? Como vou supor algo que _não_ vi? Ah, que bom que notou. http://listas.postgresql.org.br/pipermail/pgbr-geral/2009-October/017617.html Ainda acha que tem algo errado no meu modelo de dados sem ter essas informações? Posso estar errado (pois não vi a sua estrutura) mas já presenciei vários cenários em que combinei alguns índices e diminuí consideravelmente o número deles sem prejudicar as consultas que os utilizam. Assim, eu consegui aumentar o número de DML/s consideravelmente. Ah, isso certamente ajudaria. Algum exemplo concreto em que isso funcionou para você? Algum método automatizado ou pelo menos sistemático de como fazer isso? Não posso me dar ao luxo de usar o método da tentativa-e-erro num modelo com 900 tabelas e mais de 3000 chaves estrangeiras. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. Como tu farias integridade referencial em um TXT? Não menospreze anos de pesquisa em teoria de SGBDs. Citei o caso extremo caso desempenho nas gravações fosse meu problema. Não é. Por enquanto o custo desse monte de índices (mesmo nas consultas, como bem explicado pelo Charly) ainda é muito menor do que o benefício de sua eventual utilização. 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] Aumentar Número de Indices por Tabe la
Euler, Mozart Hasse escreveu: Euler escreveu: Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Ué, errado por quê?! Simplesmente porque atualizar um registro implica em atualizar pelo menos 1 + 32 + 1 arquivos. Isso é uma operação muito custosa senão inviável em alguns cenários. Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão simplório?! O Oracle e SQL Server por exemplo só tocam num índice se a atualização se referir a campos pertencentes a ele. Quanto a inserções (em que pelo menos todos os índices *não condicionais* são atualizados), obviamente elas serão relativamente mais lentas com índices (se você medir com precisão a média em milissegundos), mas isso nem de longe pode ser considerado um problema conceitual, pois dados são inseridos para serem consultados. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. Já que você acha que conhece jeitos menos errados de modelar uma tabela que você nem sabe para que serve, nem quantos registros tem, nem a que consultas é submetida, manda lá sua sugestão sobre o que faço para tornar mais rápidas as gravações sem tornar imprestáveis as consultas à minha tabelinha de 89 campos, 20 chaves estrangeiras, 44 índices e não menos do que 10 registros. Isso, claro, se você achar que tem argumentos para discordar do que eu disse anteriormente: Esquartejar essa tabela em duas ou mais considerando que eu quase sempre uso todos os 89 campos juntos soa não só como um contra-senso como prejudica muito qualquer esperança de desempenho. 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] Aumentar Número de Indices por Tabe la
Antes de mais nada, sr. Mozart, peço que o tom nestas mensagens que tens enviado seja menos agressivo. Não estamos aqui na lista para ler emails agressivos. Quanto a ter mais de 10 registros, isso para um banco de dados não é muita coisa. Não conheço teu aplicativo para dizer se realmente há algo de errado ou não, assim não entrarei nesse mérito. Contudo nem sempre criar tantos índices ajuda na busca (independente do SGBD utilizado), pelo contrário, pode até atrapalhar. Imagino que o que foi pensado foi avisar-te para analisar a necessidade real de tantos índices. Lembre-se de que muitos nesta lista trabalham ou já trabalham com datawarehouses e ERPs também, assim talvez possam ajudar a adequar teu modelo com o postgresql (caso desejes essa ajuda). E quanto ao sr. Euler, ele é uma das pessoas que mais conhece postgreSQL no Brasil, não menospreze os dizeres dele; pode ser até que em algum ponto erre (ele é humano como todos nós), mas sabe muito mais de que possa parecer e nunca o vi negar passar conhecimento. Atenciosamente, consultar, meteria os dados num arquivo TXT, não num banco de dados. Já que você acha que conhece jeitos menos errados de modelar uma tabela que você nem sabe para que serve, nem quantos registros tem, nem a que consultas é submetida, manda lá sua sugestão sobre o que faço para tornar mais rápidas as gravações sem tornar imprestáveis as consultas à minha tabelinha de 89 campos, 20 chaves estrangeiras, 44 índices e não menos do que 10 registros. Isso, claro, se você achar que tem argumentos para discordar do que eu disse anteriormente: Esquartejar essa tabela em duas ou mais considerando que eu quase sempre uso todos os 89 campos juntos soa não só como um contra-senso como prejudica muito qualquer esperança de desempenho. Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Se eu quisesse gravar mais rápido do que -- André de Camargo Fernandes ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
2009/10/2 Mozart Hasse mozart.ha...@usa.net: Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão simplório?! 1 + 32 + 1. 1 para escrever no log. 32 outros arquivos sendo um para cada índice. 1 para a tabela. -- Mozart, a única *coisa estranha* que *eu* vejo é a necessidade de usar 44 índices. Provavelmente você está criando um para cada coluna. Você mesmo disse: ... eu quase sempre uso todos os 89 campos ... Então crie 1 índice contendo todas as colunas que fazem referência às dimensões. Mesmo que você faça uma consulta que não utilize estas colunas no filtro, a consulta ainda poderá usar o índice parcialmente. Não crie também índices malucos como exemplo: 1 índice para cd_cliente, outro para cd_produto e outro para as duas colunas: cd_cliente e cd_produto. Apenas crie 1 índice para as 2 colunas. Entende? Novamente eu recomendo para você o livro: http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704 -- O amigo Andre pouco tempo atrás já falou sobre os propósitos desta lista e de nossa boa vontade. Gostaria de acrescentar apenas o seguinte: No processo de aprendizado devemos quebrar nossos paradigmas. Resetar nossos conceitos. Entender o que a outra pessoa está querendo dizer para depois apelar para o que já sabemos e escolher por em pratica o novo conhecimento adquirido. Quando comecei a estudar os conceitos de um Data Warehouse, fiquei abismado com a idéia de quebrar totalmente as formas normais, e criar um esquema em estrela[1]. Depois eu entendi o porque. Se tivesse sido contrario e rejeitado a informação nunca conseguiria construir um Warehouse decente. [1] http://en.wikipedia.org/wiki/Star_schema -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Mozart Hasse escreveu: Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão simplório?! O Oracle e SQL Server por exemplo só tocam num índice se a atualização se referir a campos pertencentes a ele. O PostgreSQL também (vide HOT) mas como *não* sei a que versão se refere preferi afirmar algo conservador... Quanto a inserções (em que pelo menos todos os índices *não condicionais* são atualizados), obviamente elas serão relativamente mais lentas com índices (se você medir com precisão a média em milissegundos), mas isso nem de longe pode ser considerado um problema conceitual Conceito *não*, mas de organização física. Você *não* mostrou essa tal tabela, os índices dela e, o mais importante, as estatísticas de uso desses índices. Posso estar errado (pois não vi a sua estrutura) mas já presenciei vários cenários em que combinei alguns índices e diminuí consideravelmente o número deles sem prejudicar as consultas que os utilizam. Assim, eu consegui aumentar o número de DML/s consideravelmente. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. Como tu farias integridade referencial em um TXT? Não menospreze anos de pesquisa em teoria de SGBDs. Já que você acha que conhece jeitos menos errados de modelar uma tabela que você nem sabe para que serve, nem quantos registros tem, nem a que consultas é submetida, manda lá sua sugestão sobre o que faço para tornar mais rápidas as gravações sem tornar imprestáveis as consultas à minha tabelinha de 89 campos, 20 chaves estrangeiras, 44 índices e não menos do que 10 registros. Ugh? Como vou supor algo que _não_ vi? -- 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] Aumentar Número de Indices por Tabe la
Senhores, boa noite... Vou entrar na conversa também. Com relação a índices, sempre é um assunto polêmico, mas muito interessante, e de extrema importância no nosso trabalho. Bem, não conheço a aplicação em questão, logo o que eu falar aqui será com base em conceitos e boas práticas relacionadas a aplicação dos mesmos. Concordo com o que o Euler colocou sobre a quantidade excessiva de índices, uma vez que o SGBD não utiliza mais de um índice por pesquisa são extremos os casos onde há a necessidade de mais de 5 índices por tabela. Entendam são raros, e não impossíveis. Existem problemas e situações onde isso não se aplique, mas lembrem-se, apenas um dos tantos índices será utilizado na pesquisa. Outro ponto importante, é o índice utilizado... Qual algorítmo? Quais os tipos envolvidos? Com relação a atualização, assim como em uma pesquisa, o uso de índice não é simplório, tendo em vista que o SGBD pode fazer uso de um índice mesmo que o índice não esteja envolvido diretamente na pesquisa (vejam que aumentamos a complexidade aqui!) a atualização também não é simplória ao ponto de o SGBD não tocar em um índice que não esteja envolvido na atualização da entidade. Isso digo não apenas do PostgreSQL, mas do Oracle e DB2. As implicações em termos muitos índices são muitas, e o custo de manutenção dos mesmos devem ser levados em conta sim! Compreendo que aplicações de BI/DW se utilizam de uma técnica não ortodoxa de modelagem, e que muitos conceitos referentes a normalização são de certa forma desprezados em virtude de aumento na performance das pesquisas, até porque não são bases OLTP com auto indice transacional. Logo são aplicações não ortodoxas, que se dão ao direito de não terem preocupações com custos e perdas no momento de atualização. Ainda assim, a grande quantidade de índices não implica diretamente na melhoria da performance das buscas, pois se os mesmos não forem bem planejados, podemos ter índices nunca utilizados ocupando espaço desnecessário, e infringindo uma perda também desnecessária inclusive no momento da pesquisa, pois o otimizador pode, e eventualmente vai, perder tempo em desconsiderar aquele índice como um candidato não eletivo. Lembrem-se, ainda que não utilizado, ele faz parte do dicionário de dados, o qual é utilizado pelo otimizador no momento de decidir qual índice eleger para pesquisa. Bem, finalizando (ainda que querendo falar mais... :-D), podemos perceber que o tema é complexo, e não simplista... Existem muitos pontos e variáveis a serem observadas... Todavia, a minha recomendação é, não extrapolem na utilização de índices, vão infringir uma carga muito grande de trabalho ao SGBD, e aqui indifere o SGBD. Comecem sempre com implementações conservadoras, e a medida que o tempo passar e existirem informações, apliquem as melhorias de tunning e performance necessária. Primem por manter saudável o SGBD, e o excesso de índice pode comprometer a saúde do mesmo! Ah, e antes que me esqueça... Senhores, acalmem-se, estamos aqui para nos ajudar. Não deixemos que a sexta-feira e o cansaço leve para o lado pessoal nossos debates. Eles são muito construtivos, ainda que não concordemos com todos os pontos de vista apresentados. Um grande abraço a todos, e um excelente final de semana! -- Charly Frankl http://javadevilopers.blogspot.com/ charlyfra...@gmail.com Linux user #391083 2009/10/2 Euler Taveira de Oliveira eu...@timbira.com Mozart Hasse escreveu: Como assim pelo menos 1+32+1?! Tem certeza que o Postgres ainda é tão simplório?! O Oracle e SQL Server por exemplo só tocam num índice se a atualização se referir a campos pertencentes a ele. O PostgreSQL também (vide HOT) mas como *não* sei a que versão se refere preferi afirmar algo conservador... Quanto a inserções (em que pelo menos todos os índices *não condicionais* são atualizados), obviamente elas serão relativamente mais lentas com índices (se você medir com precisão a média em milissegundos), mas isso nem de longe pode ser considerado um problema conceitual Conceito *não*, mas de organização física. Você *não* mostrou essa tal tabela, os índices dela e, o mais importante, as estatísticas de uso desses índices. Posso estar errado (pois não vi a sua estrutura) mas já presenciei vários cenários em que combinei alguns índices e diminuí consideravelmente o número deles sem prejudicar as consultas que os utilizam. Assim, eu consegui aumentar o número de DML/s consideravelmente. Se eu quisesse gravar mais rápido do que consultar, meteria os dados num arquivo TXT, não num banco de dados. Como tu farias integridade referencial em um TXT? Não menospreze anos de pesquisa em teoria de SGBDs. Já que você acha que conhece jeitos menos errados de modelar uma tabela que você nem sabe para que serve, nem quantos registros tem, nem a que consultas é submetida, manda lá sua sugestão sobre o que faço para tornar mais rápidas as gravações sem tornar imprestáveis as consultas à minha tabelinha de 89
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Olá pessoal, refiz tudo novamente mais sem sucesso... editei o config_manual pra 64, mas continua na mesma. 2009/10/1 Tarcísio Sassara sassara.tarci...@gmail.com 2009/10/1 Fernando Maia maia...@gmail.com: esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. Mas Fernando, está correto. Estas colunas identificam um registro na tabela fato. Explicando um pouco melhor: O banco de dados de produção, ou seja, aquele que é utilizado pela aplicação do cliente deve ser separado do banco que será o Data Warehouse. Não da para usar um mesmo modelo para as duas coisas: Produção e Análise. Primeiro vem o banco produção onde você vai criar todas as tabelas com as chaves primarias e estrangeiras, índices e se possível, seguindo as formas normais. Depois vem o banco warehouse que deve conter uma estrutura especifica para este problema. Uma dica para o warehouse que tem muitas dimensões é ver se você não está colocando 2 vezes a mesma dimensão. Ex: Uma coluna apontando para uma dimensão ano e outra apontando para mês, quando o correto seria uma única referência para uma dimensão chamada data. Depois você deve criar um script que transforma e envia os dados do banco produção para o banco warehouse. Claro, se você estiver carregando os dados vindos de um arquivo de texto, você não terá um banco em produção. Somente terá o warehouse. Eu lhe recomendo um livro muito bom: The Data Warehouse Toolkit (Ralph Kimball) http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704 Abraço! -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
Fernando Maia escreveu: Olá pessoal, refiz tudo novamente mais sem sucesso... editei o config_manual pra 64, mas continua na mesma. Você verificou o caminho dos binários do PostgreSQL? Você verificou o caminho do $PGDATA? Pelo menos um dos dois devem estar apontando para o local errado. -- 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] Aumentar Número de Indices por Tabe la
Ué, Fernando Maia escreveu: Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Meu recorde é 44 índices numa tabela com 89 campos e 20 FKs, isso porque as outras 40 colunas menos usadas já foram para uma tabela auxiliar. E olha que é um sistema ERP, imagina quando meterem isso num datawarehouse... Euler escreveu: Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Ué, errado por quê?! Tabelas normalizadas têm por definição um monte de FKs, e cada uma delas quase sempre precisa de um ou dois índices. Esquartejar essa tabela em duas ou mais considerando que eu quase sempre uso todos os 89 campos juntos soa não só como um contra-senso como prejudica muito qualquer esperança de desempenho. 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] Aumentar Número de Indices por Tabe la
Oi Fernando, 2009/10/1 Fernando Maia maiaapc em gmail.com: Em um DW eu coloco na tabela fato as chaves estrangeiras de cada dimensão e coloco apenas um índice contendo todas estas chaves. Conceitualmente correto *s*e* não houver dependências funcionais entre as chaves. Se houver, ou seja, de os valores de algumas chaves determinarem os valores de outras (por exemplo, se você tiver chaves separadas para dia, mês, ano e dia da semana), aí a utilidade mesmo que *conceitual* (porque utilidade prática não tem nenhuma) de uma chave primária com todos os campos é bastante questionável. esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. Ah, que bonitinho... e o que é que o modelo lógico tem a ver com a implementação?! É uma fonte inspiradora ou emburrecedora? Nada contra imaginar um banco de dados com desempenho infinito, número de campos infinito e sem limite de espaço, porém na hora de colocar em prática os conceitos e entidades planejadas pode ser necessário representá-las ou armazená-las em objetos separados ou similares. Afinal, o desempenho não é conceitual, o trabalho é concreto e portanto deve oferecer um ganho de desempenho concreto comparado com consultas diretas aos dados de origem. Se os próprios livros de análise e banco de dados já falam que temos como etapas a elaboração do modelo *lógico* (conceitual, com a chave primária inútil que ela quer) e do modelo *físico* (viável, útil e eficiente), por que ela vai querer misturar? Convença ela a ponderar melhor esse idealismo conceitual. *Nenhum* banco de dados aceita muitos campos num índice exatamente porque tratar campos demais torna o índice menos eficiente, ainda mais numa chave primária. O limite do Postgres (32 campos num índice) já é muito alto comparado com outros bancos de dados, e querer superá-lo só por um capricho conceitual precisa de uma excelente justificativa. O ônus da prova cabe a quem afirma. Pelo que entendi ela alega que *deve* ser desse jeito. Pois bem, pode começar perguntando a ela de qual parágrafo de que livro ela *pensa* que tirou essa idéia, pois nem no meio acadêmico ouvi falar dessa necessidade. 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] Aumentar Número de Indices por Tabe la
Mozart Hasse escreveu: Euler escreveu: Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Ué, errado por quê?! Simplesmente porque atualizar um registro implica em atualizar pelo menos 1 + 32 + 1 arquivos. Isso é uma operação muito custosa senão inviável em alguns cenários. -- 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] Aumentar Número de Indices por Tabe la
Fernando Maia escreveu: Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Em todo caso, você precisará recompilar o PostgreSQL após alterar o parâmetro INDEX_MAX_KEYS no arquivo src/include/pg_config_manual.h. Além disso, você precisará executar o initdb novamente, ou seja, terá que fazer uma cópia de segurança (aka _dump_) e uma restauração (aka _restore_). -- 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] Aumentar Número de Indices por Tabe la
Olá Euler, a resposta é sim preciso de mais de 32 indices em uma tabela, no caso estou desenvolvendo um data warehouse, e minha tabela fato tera mais de 32 dimensões, o por isso de fazer essa modificação. Eu sei dessa alteração no pg_config_manual.h, mas não sei se fiz certo... o que eu fiz foi o seguinte: baixei o postgres.tar.gz alterei o pg_config_manual.h e compilei e instalei o postgres... mas não resolveu meu problema. Será que fiz da forma correta? Agradeço a atenção 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Fernando Maia escreveu: Gostaria de pedir a ajuda de vocês, estou precisando aumentar o meu número de indices por tabela, que por default aceita no máximo 32 indexações. Você está querendo ter mais do que 32 índices em uma tabela? Há algo errado com o seu modelo de dados, não? Em todo caso, você precisará recompilar o PostgreSQL após alterar o parâmetro INDEX_MAX_KEYS no arquivo src/include/pg_config_manual.h. Além disso, você precisará executar o initdb novamente, ou seja, terá que fazer uma cópia de segurança (aka _dump_) e uma restauração (aka _restore_). -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/9/30 Fernando Maia maia...@gmail.com: Eu sei dessa alteração no pg_config_manual.h, mas não sei se fiz certo... o que eu fiz foi o seguinte: baixei o postgres.tar.gz alterei o pg_config_manual.h e compilei e instalei o postgres... mas não resolveu meu problema. Então colega, se você baixo o Postgres, alterou o arquivo pg_config_manual.h depois configurou, compilou, instalou e criou o cluster com initdb, não deveria dar problemas. Eu recomendo dar uma revisada nos passos que você seguiu. Se você já tiver feito as operações acima sem antes ter alterado o pg_config, você vai precisar configurar, compilar, instalar e criar um novo cluster com o initdb. Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: drop table if exists teste; create table teste ( cola integer not null, colb integer not null, colc integer not null, cold integer not null, cole integer not null, colf integer not null, colg integer not null, colh integer not null, coli integer not null, colj integer not null, colk integer not null, coll integer not null, colm integer not null, coln integer not null, colo integer not null, colp integer not null, colq integer not null, colr integer not null, cols integer not null, colt integer not null, colu integer not null, colv integer not null, colw integer not null, colx integer not null, coly integer not null, colz integer not null, cola2 integer not null, colb2 integer not null, colc2 integer not null, cold2 integer not null, cole2 integer not null, colf2 integer not null, colg2 integer not null, colh2 integer not null, coli2 integer not null, colj2 integer not null, colk2 integer not null, coll2 integer not null, colm2 integer not null, coln2 integer not null, colo2 integer not null, colp2 integer not null, colq2 integer not null, colr2 integer not null, cols2 integer not null, colt2 integer not null, colu2 integer not null, colv2 integer not null, colw2 integer not null, colx2 integer not null, coly2 integer not null, colz2 integer not null); create index teste_idx on teste using btree ( cola, colb, colc, cold, cole, colf, colg, colh, coli, colj, colk, coll, colm, coln, colo, colp, colq, colr, cols, colt, colu, colv, colw, colx, coly, colz, cola2, colb2, colc2, cold2, cole2, colf2, colg2, colh2, coli2, colj2, colk2, coll2, colm2, coln2); -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. -- 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] Aumentar Número de Indices por Tabe la
exato... na realidade preciso fazer isso: create table fato( coluna01 integer, coluna02 integer, coluna03 integer, . . . coluna50 integer, PRIMARY KEY(coluna01,coluna02,coluna03...coluna50) ); 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/9/30 Euler Taveira de Oliveira eu...@timbira.com: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. 1: Foi mals. Acho que não entendi/li direito. =D 2: Nunca vi isso. Em um DW eu coloco na tabela fato as chaves estrangeiras de cada dimensão e coloco apenas um índice contendo todas estas chaves. E de qualquer maneira, a constante INDEX_MAX_KEYS encontrada no pg_config_manual se refere a quantidade maxíma de colunas em um índice e não a quantidade de índices por tabela. -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
2009/9/30 Fernando Maia maia...@gmail.com: exato... na realidade preciso fazer isso: create table fato( coluna01 integer, coluna02 integer, coluna03 integer, . . . coluna50 integer, PRIMARY KEY(coluna01,coluna02,coluna03...coluna50) ); Opá, opá. Então, da uma olhada lá no arquivo pg_config_manual. O único detalhe sobre performance é colocar um número múltiplo de 32. Talvez 64 resolva, não? E siga tudo do começo: configura, compila, instala e cria o cluster com initdb. Abraço. -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Aumentar Número de Indices por Tabe la
Eu escrevi: Tarcísio Sassara escreveu: Os comandos abaixo para criar uma tabela e um índice com 40 colunas deu certo: Ele não quer criar um índice de 40 colunas e sim 40 índices em uma tabela. Opsss... [Faltando cafeína a essa hora da noite] É isso mesmo. Índice com 40 colunas. -- 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] Aumentar Número de Indices por Tabe la
Fernando Maia escreveu: Será que fiz da forma correta? Você tem que executar o initdb novamente para criar outro _cluster_. -- 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] Aumentar Número de Indices por Tabe la
Olá pessoal, Eu gostaria de discutir isso com vcs: Em um DW eu coloco na tabela fato as chaves estrangeiras de cada dimensão e coloco apenas um índice contendo todas estas chaves. esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. 2009/9/30 Euler Taveira de Oliveira eu...@timbira.com Fernando Maia escreveu: Será que fiz da forma correta? Você tem que executar o initdb novamente para criar outro _cluster_. -- 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 -- Fernando Maia Acadêmico Sistemas de Informação-CPCX-UFMS msn: maia_...@hotmail.com email: maia...@gmail.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] Aumentar Número de Indices por Tabe la
2009/10/1 Fernando Maia maia...@gmail.com: esse DW é um trabalho da universidade, minha tutora ensiste em dizer que a fato deve ser criada daquela forma, segundo ela, faz parte do modelo lógico da tabela fato a criação de todas as dimensões como primary key. Mas Fernando, está correto. Estas colunas identificam um registro na tabela fato. Explicando um pouco melhor: O banco de dados de produção, ou seja, aquele que é utilizado pela aplicação do cliente deve ser separado do banco que será o Data Warehouse. Não da para usar um mesmo modelo para as duas coisas: Produção e Análise. Primeiro vem o banco produção onde você vai criar todas as tabelas com as chaves primarias e estrangeiras, índices e se possível, seguindo as formas normais. Depois vem o banco warehouse que deve conter uma estrutura especifica para este problema. Uma dica para o warehouse que tem muitas dimensões é ver se você não está colocando 2 vezes a mesma dimensão. Ex: Uma coluna apontando para uma dimensão ano e outra apontando para mês, quando o correto seria uma única referência para uma dimensão chamada data. Depois você deve criar um script que transforma e envia os dados do banco produção para o banco warehouse. Claro, se você estiver carregando os dados vindos de um arquivo de texto, você não terá um banco em produção. Somente terá o warehouse. Eu lhe recomendo um livro muito bom: The Data Warehouse Toolkit (Ralph Kimball) http://www.amazon.com/exec/obidos/ASIN/0471200247/ralphkimballc-20/104-5050702-4100704 Abraço! -- Tarcisio F. Sassara ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
