Angelo, boa tarde... Vou me intrometer um pouco no assunto tb... rsss
Para começar um bom projeto vc precisa conhecer bem o negócio do teu cliente, saber quais suas reais necessidades... No projeto você pode estimar, com base na necessidade do cliente quais entidades serão mais ou menos acessadas, prever consultas e relatórios. Com relação a modelagem de dados e utilização de indices, a melhor estratégia é a simplicidade. Comece criando as entidades de "apoio", com seus indices primários. Depois, quando da criação das entidades mais complexas, conhecendo um pouco do negócio do cliente você poderá prever se as entidades terão muitos acessos ou não, e que tipos de acessos terão. Lembro, poderá PREVER! Todavia, todo sistema quando entra em produção necessita de um tuning, onde você deverá incluir ou retirar indices. E tuning, só pode ser feito com sistema em atividade, pois ai você terá informações para isso, senão, continuarão sendo previsões. Lembro, um indice não é a solução para todos os problemas. Os maiores problemas começam com uma modelagem ruim... Nesse caso, um indice não irá corrigir o problema. Outra coisa, indices também possuem custos. Principalmente para atualizações nas entidades (insert/update/delete), pois os mesmos serão alterados também. Se você prevê que uma entidade não terá muitos acessos de consultas, mas muitos acessos transacionais, poderá retirar todos os indices de chave estrangeira da mesma (caso existam). Existem situações, onde vale a pena criar um indice temporário para atender a necessidade de um relatório. Depois da emissão do mesmo remover o indice. Existem situações também onde o acesso sequencial a tabela é muito mais "barato" ao banco. Nesse caso, um indice além de desnecessário, é um custo adicional. Logo, não existe formula mágica. Existem sim boas práticas, e temos literaturas muito boas a respeito. Pode começar pelos clássicos C.J. Date, Edgar Codd, Hugh Darwen... dentre outros. 2009/8/4 Euler Taveira de Oliveira <[email protected]> > Angelo Augusto Frozza (UNIPLAC) escreveu: > > [Como o amigo Osvaldo costuma dizer: *não* "sequestre" um assunto, ao invés > disso, crie uma nova mensagem; isso bagunça o histórico da lista] > > > Estou iniciando um estudo sobre estratégias para melhor definir índices > para > > um banco de dados. > > > > A idéia surgiu como uma pesquisa voltada para um aluno calouro, mas agora > > passou para um aluno em fase de iniciar o TCC e estou em dúvida na > > organização da estrutura do trabalho. > > > > Inicialmente, tenho percebido em nosso curso pouca preocupação com a > > modelagem de BD e com a definição correta de índices, sendo que o pessoal > > limita-se a chave-primária e chave-estrangeira apenas. > > > Nem sempre uma chave estrangeira precisa de índices; tanto é que o > PostgreSQL > *não* cria índices para chaves estrangeiras. > > > O trabalho, a princípio, foca o estudo exclusivamente para o banco de > dados > > PostgreSQL e nossos objetivos são: > > - Identificar quais estratégias para definição de índices otimizados são > > mais utilizadas; > > - Identificar em que situações cada estratégia é mais indicada; > > > Como assim estratégia? As estratégias que posso visualizar são: > (i) criar ou não um índice; > (ii) remover um índice; > (iii) tipo do índice; > (iv) 2 índices em (a) e (b) ou 1 índice em (a, b). > > Prever quais os índices são necessários na fase de projeto de banco de > dados, > às vezes, não é uma tarefa fácil (vide a literatura). Por quê? Simplesmente > porque é difícil saber se o índice vai ser útil ou não (estratégia (i)). > Para > saber se um índice vai ser útil temos que conhecer as consultas executadas, > a > ordem (dezenas, centenas, milhares, ...) da quantidade de registros e até > mesmo a seletividade dos dados a serem indexados. Talvez as duas primeiras > heurísticas citadas anteriormente sejam as mais utilizadas por DBAs para > definir se um índice vai ser criado ou não na fase de projeto; e, mesmo > assim > pode ser uma suposição errada. > > No mais, a análise de índices fica para a fase após a implantação. É > justamente com o sistema em operação que podem visualizar como a consulta e > mudança dos dados estão ocorrendo. > > > - Criar um tutorial, na forma de Wiki, para socializar o estudo sobre a > > adoção de índices otimizados em bancos de dados livres. > > > Uma dica é colocar isso em [1] ou no espaço brasileiro [2]. > > > A grande dúvida é se existe teoria aplicada sobre a criação de índices > > durante (ou logo após) a fase de projeto do BD, ou essa preocupação de > > otimizar os índices é resolvida pela modelagem ou, em último caso, so vai > > ser interessante mesmo quando o sistema precisar uma análise de > otimização. > > > A preocupação com índices só vem a tona quando o sistema já está em > operação. > Por quê? Nessa fase, podemos coletar dados (consultas e estatísticas de > índices, por exemplo) para podermos executar as estratégias (i), (ii) e > (iv) > com uma maior eficiência. > > Talvez as estratégias (ii) e (iv) sejam as mais difíceis nesta ordem. > Podemos > ter índices que são utilizados mas em casos raros e não trariam maiores > problemas caso ele fosse removido. No caso da estratégia (iv), podemos ter > que > decompor um índice para que mais consultas possam se beneficiar deles ou > > Assim, os SGBDs possuem ferramentas de análise (a posteriori) para definir > se > índices são úteis ou não e sugerir a criação caso sejam benéficos. Vide a > ferramenta [3] ou os trabalhos do Prof. Sergio [4]. > > > [1] > http://wiki.postgresql.org/wiki/Database_Administration_and_Maintenance > [2] http://wiki.postgresql.org/wiki/Portugu%C3%AAs > [3] http://pgfoundry.org/projects/pgadviser/ > [4] > http://www.inf.puc-rio.br/~postgresql/index.php?acao=grupopesquisa<http://www.inf.puc-rio.br/%7Epostgresql/index.php?acao=grupopesquisa> > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Charly Frankl http://javadevilopers.blogspot.com/ [email protected] Linux user #391083
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
