Minhas duas perguntas são:

Posso usar índices agrupados para acelerar inserções em massa em grandes tabelas?Ainda posso usar com eficiência relacionamentos de chave estrangeira se minha coluna IDENTITY não for mais o índice em cluster?

Para elaborar, eu tenho um banco de dados com algumas tabelas muito grandes (entre 100-1000 mln linhas) contendo dados da empresa. Normalmente, existem dados de 20 a 40 empresas nessa tabela, cada um com seu próprio "pedaço" marcado por "CompanyIdentifier" (INT). Além disso, toda empresa possui cerca de 20 departamentos, cada um com seu próprio "subchunk" marcado por "DepartmentIdentifier" (INT).

Freqüentemente acontece que um "pedaço" ou "sub-pedaço" inteiro é adicionado ou removido da tabela. Meu primeiro pensamento foi usar o particionamento de tabela nesses blocos, mas como estou usando o SQL Server 2008 Standard Edition não tenho direito a ele. Ainda assim, a maioria das consultas que tenho são executadas em um "pedaço" ou "sub-pedaço", e não na mesa como um todo.

Eu tenho trabalhado para otimizar essas tabelas para as seguintes funções:

Consultas executadas em sub-blocosConsultas de "benchmarking" executadas na tabela como um todoInserindo / removendo grandes pedaços de dados.

Para 1) e 2) não encontrei muitos problemas. Criei vários índices nos campos-chave (também contendo CompanyIdentifier e DepartmentIdentifier, quando úteis) e as consultas estão sendo executadas corretamente.

Mas para 3) lutei para encontrar uma boa solução. Minha primeira estratégia foi sempre desabilitar índices, inserir em massa uma grande parte e reconstruir índices. Isso foi muito rápido no começo, mas agora que existem muitas empresas no banco de dados, leva muito tempo para reconstruir o índice a cada vez.

No momento, minha estratégia mudou para apenas deixar o índice ativado durante a inserção, pois isso parece ser mais rápido agora. Mas quero otimizar ainda mais a velocidade da pastilha.

Parece que percebi que, adicionando um índice clusterizado definido no CompanyIdentifier + DepartmentIdentifier, o carregamento de novos "pedaços" na tabela é mais rápido. Antes de abandonar essa estratégia em favor da adição de um índice clusterizado em uma coluna IDENTITY, como vários artigos apontaram para mim que o índice clusterizado está contido em todos os outros índices e, portanto, o índice clusterizado deve ser o menor possível. Mas agora estou pensando em reviver essa estratégia antiga para acelerar as inserções. Minha pergunta, isso seria sensato, ou sofrerei impactos de desempenho em outras áreas? E isso realmente vai acelerar minhas inserções ou isso é apenas minha imaginação?

Também não tenho certeza se, no meu caso, é realmente necessária uma coluna de IDENTIDADE. Gostaria de poder estabelecer relacionamentos de chave estrangeira com outras tabelas, mas também posso usar algo como um esquema CompanyIdentifier + DepartmentIdentifier + [uniquifier] para isso? Ou precisa ser um número de IDENTIDADE fragmentado em toda a tabela?

Muito obrigado por quaisquer sugestões ou explicações.