De vez em quando, um precisa de um cheque. Este é um momento.
Eu tenho tabelas que são usadas para relatórios. Eles são excluídos/inseridos uma vez por dia ou várias vezes por dia para "atualizar os dados" da fonte sempre usando um intervalo de datas contínuo (como mês até a data ou 45 dias contínuos). Os dados de origem não têm ID ou exclusividade para eles.
A convenção até agora tem sido usar um índice clusterizado na data - toda tabela tem uma data e toda consulta usa uma data (99% das vezes). Se a tabela tiver uma(s) coluna(s) que a torne(m) única(s), eu as adicionei ao cluster para torná-la única (por exemplo, status e email). Caso contrário, adicionei uma ID IDENTITY para torná-la única.
A pesquisa parece aconselhar "usar um ID de incremento" com poucos desvios. No entanto, o desempenho usando esta convenção tem sido excelente - a menos que esteja faltando algo em algum lugar.
Então, embora isso tenha sido bom, às vezes uma verificação de pares pode ser uma coisa boa :)
- Algum problema com a data como a coluna principal em um índice clusterizado (considerando o acima)?
- Adicionar a coluna MY OWN ID Identity para exclusividade é melhor do que o MS SQL fazendo isso por mim?
- Adicionar o ID primeiro e depois a data seria melhor?
Ambiente: Azure SQL
Nenhum que eu possa pensar de cabeça. Normalmente, é bom agrupar em uma coluna que seja do tipo não aleatório/sequencial. As datas geralmente se encaixam bem nesse critério, ao contrário dos GUIDs (
UNIQUEIDENTIFIERS) que estão por toda parte. O índice clusterizado é a classificação lógica da tabela real (em uma estrutura de dados B-Tree). Ao usar um tipo de dados não aleatório ou sequencial como a chave de índice, isso permite a máxima eficiência ao buscar esse subconjunto da B-Tree para todas as linhas relevantes.Não conheço nenhuma razão para fazer isso, mas vou assumir que você não está prejudicando muito fazendo isso porque está usando uma
IDENTITYcoluna que também estou assumindo que raramente muda. A única desvantagem é que você está tornando seu índice clusterizado um pouco mais gordo. Se você planeja usar quaisquer índices não clusterizados, eles também ficarão um pouco mais pesados como resultado, pois todos os índices não clusterizados também armazenam a chave de índice clusterizado. Se você planejasse usar uma coluna que fosse atualizada com frequência como parte de sua chave de índice clusterizado, isso não seria tão bom para o desempenho, pois toda vez que o valor da chave fosse alterado, ele teria que atualizar todas as linhas relacionadas em todos os índices não clusterizados também, causando muita sobrecarga adicional com o bloqueio.Não, provavelmente não. Se suas consultas não estiverem usando o
IDcampo nos predicados (JOIN,WHERE,HAVINGcláusulas), então começar com ele em seu índice fará com que esse índice não seja mais aplicável a essas consultas. Novamente, isso ocorre porque os dados são classificados logicamente na ordem dos campos definidos no índice. Se a B-Tree foi classificadaIDprimeiro, mas sua consulta não foi filtrada porID, o SQL Engine não teria uma maneira eficiente de percorrer a B-Tree diretamente para o subconjunto de linhas que sua consulta filtra.