Está criando parte do índice do banco de dados do processo de design, implementação ou otimização?

5

Existem algumas questões sobre este assunto:

  • A criação de todos os índices está no início (design) da engenharia?
  • Na realidade, adicionei índices depois que os problemas de desempenho foram encontrados e "explicamos o plano" e adicionamos índices conforme necessário (ou seja, não para todos os relacionamentos). Devo simplesmente pular a criação de índices antes que seja necessário, porque os problemas de desempenho aparecerão de qualquer maneira e provavelmente os índices que já foram criados não estão sendo usados?
  • Os índices devem ser tratados como parte do requisito / especificação? Às vezes, vejo requisitos de desempenho, que geralmente são vagos ou aleatórios. Se eles são parte da especificação, então o gerenciamento de índices deve fazer parte da implementação?

Eu quero deixar um pouco mais claro e mais fundo. Em desenvolvimento, geralmente as diferentes fases envolvem diferentes tipos de pessoas (por exemplo, arquitetos, idosos e juniores). Seria incomum que os juniores fossem responsáveis pelo design, por exemplo. Assim, quando algumas tarefas se sobrepõem, fica incerto quem é responsável se, por exemplo, uma consulta demora 2 segundos.

A definição de fases e responsabilidades de desenvolvimento também é importante para não programadores, e. gerentes de projeto ou proprietários de produtos, porque são necessários para planejamento e cálculo de custos. Um gerente de projeto pode querer aumentar um arquiteto para executar todas as tarefas relacionadas ao banco de dados apenas no início e por um curto período de tempo. Se após o lançamento do produto, for constatado que o desempenho é ruim, o PM gostaria de saber quem é o responsável. Eu espero que você entenda a ideia.

    
por imel96 06.08.2013 / 01:23
fonte

3 respostas

4

Para fins de discussão, vamos ser específico no que queremos dizer (e presumir que você está fazendo TDD):

  • Design é o processo de especificar a forma total do seu sistema. Você pode (e algumas vezes deve) projetar sem escrever direta ou indiretamente uma única linha de banco de dados ou código de programa. Você define seus Testes de Aceitação como o último estágio do design.
  • Implementação é o processo de transformar esse design em um software "funcional". Se você estiver sendo dogmático, não escreverá um único índice de banco de dados; você apenas definiria as tabelas, escreveria o objeto de interface e confiaria em sua plataforma de nível inferior para carregar os dados. Você escreve Testes de Unidade e Testes de Integração durante a implementação, e a implementação é feita quando os Testes de Aceitação passam.
  • A Otimização está fazendo o software "funcional" que você fez em Implementação e acelerando onde ele é executado de maneira inaceitavelmente lenta. As três camadas de teste permitem que você faça alterações sem quebrar nada.

Claro, é assim que funciona na teoria. Mas, como uma questão prática, uma vez que o tempo e o dinheiro são limitados, muitas vezes você vai para as etapas fora de ordem. Se você espera precisar de um índice em um campo específico, não há razão para não indexá-lo ao projetá-lo. Se, durante uma série de códigos, você perceber como pode resolver com elegância uma situação de uso alternativo, pode codificar um rascunho primeiro e escrever o segundo teste da unidade. (E quando você perceber que seu design está errado, você terá que voltar e revisar seus testes de qualquer maneira.)

Quanto às suas perguntas particulares:

Is creating all indexes at the start (design) over engineering?

Não, se todos forem índices úteis e não demorarem muito tempo.

Sim, se você acabar definindo índices para tabelas que estão longe do primeiro protótipo bruto. (Se você criar índices em seu design inicial, submeta-os a testes posteriores. Eles podem ser mais problemas do que valem a pena.)

Should I just skip creating indexes before it's needed because performance issues will show up anyway and probably the indexes that's already been created aren't being used?

Não, se estiver claro que você precisará ter algumas colunas indexadas. Se você planeja um recurso que pesquisa com frequência lances em ações acima ou abaixo de um determinado preço, provavelmente desejará um índice sobre o valor do lance, além da chave exclusiva do registro.

Sim, se não estiver claro que o índice concederá ao sistema geral uma melhoria de desempenho. A única consulta por mês para lances feitos por estado provavelmente não precisa de um índice específico.

Should indexes be treated as part of requirement/specification?

NÃO . Os índices são um componente do design de software. Eles não têm mais lugar em requisitos ou especificações do que o uso de um método de estrutura específico ou nome de variável transitória.

(É possível que toda ou parte da programação venha de seu cliente, mas é tolice fazer uso de tal requisito. Um servidor de indexação não tem propósito se o servidor enviar a tabela inteira de qualquer maneira.)

    
por 06.08.2013 / 03:07
fonte
2

A criação de índices é um detalhe de implementação , não os considero parte de uma especificação. O design da sua estrutura de banco de dados geralmente envolve apenas a tabela & nomes de coluna e tipos de dados, não o DDL que será usado para criá-lo - e é aí que CREATE INDEX seria incluído.

Para a maioria das relações de tabelas complicadas, você não terá índices em todas as combinações possíveis de chaves, já que isso não faz sentido w.r.t. a lógica de negócios. Você deve criá-las no início em todas as chaves de entidade comumente usadas & JOIN s, e eu apenas uso o Explain Plan para capturar os casos de borda.

    
por 06.08.2013 / 03:05
fonte
-2

Sim, criar índices de banco de dados faz parte do design, implementação e otimização.

  • Um grande conjunto de índices faz parte do design. A chave primária e os índices de chave estrangeira se enquadram nessa categoria. Chaves primárias e exclusivas são caras para impor sem um índice. Se você entender bem o design, poderá omitir alguns índices de chave estrangeira. Você também pode substituir índices com colunas adicionais para o índice de chave estrangeira. Se padrões de acesso forem bem compreendidos, índices adicionais podem ser especificados. Os índices de chave primária e chave estrangeira são essenciais para unir desempenho e otimização de consulta. O design especificará chaves e índices criados durante a implementação.
  • Durante a implementação, você criará os índices resultantes do design. O modelo lógico do design pode ser modificado. Isso pode resultar em novos índices. Geralmente, a implementação deve resultar em poucos novos índices.
  • Problemas de desempenho podem revelar caminhos de acesso para os quais um índice apropriado não está disponível. Um projeto ou implementação mais completo pode ter descoberto alguns desses casos. Em outros casos, o uso real ou a distribuição de dados pode diferir do que era esperado durante o design e a implementação. A distribuição de valores de escala e índice pode ter um impacto significativo no valor de um índice para uma consulta e no plano de consulta otimizado.

A adição de todos os índices de consulta que podem ser, ou espera-se que sejam, necessários no design ou no tempo de implementação seria um exagero. Cada índice carrega uma sobrecarga e muitos índices podem ser caros.

Algumas razões pelas quais um índice pode não ser útil incluem:

  • O caminho de acesso é raramente ou nunca usado;
  • O otimizador de consulta pode escolher um caminho de acesso diferente; ou
  • Um índice parcial fornece um conjunto de registros suficientemente pequeno.
por 06.08.2013 / 02:04
fonte