Estou particionando uma tabela com base em uma coluna que não é uma chave primária? Eu li algumas informações conflitantes hoje sobre se a coluna de partição deve fazer parte da chave primária. Meu instinto diz que não, mas não tenho 100% de certeza. Então perguntas...
- A coluna de partição deve fazer parte do primário? É recomendado de uma forma ou de outra?
- Devo criar um índice para a chave de partição ou o DBMS faz isso automaticamente por conta própria?
De jeito nenhum.
Um dos cenários mais comuns de particionamento é usar um campo de data, que não tem relação alguma com o seu PK.
Por exemplo, se você tiver uma tabela
Orderscom o campoOrderDate, provavelmente particionará com base no mês e no ano deOrderDate.Quando os registros envelhecem e não são mais relevantes, você pode mover essas partições para uma tabela de arquivo ou banco de dados para que não sejam mais processadas.
O particionamento funcionará com praticamente qualquer campo, mas para que funcione BEM, o(s) campo(s) em que você particionar deve(m) ser usado(s) na maioria, se não em todas, das suas consultas. Se você não incluir suas chaves de partição, obterá essencialmente uma varredura de tabela cara que abrange várias tabelas (partições).
EDITAR
Para a parte 2, acho que a resposta também é não. A chave de partição é usada para determinar em qual partição colocar a linha, mas não acho que um índice seja mantido. Pode haver estatísticas no back-end sobre ele embora.
Além da resposta do JNK, você provavelmente deve ler este artigo que discute o alinhamento de partições de tabela e partições de índice.
Existem muitos tipos de cenários em que o esquema de particionamento segue exatamente a primeira coluna da chave primária - por exemplo, em um cenário de data warehouse em que a data do instantâneo de uma tabela de fatos geralmente é a coluna de partição, bem como a primeira coluna da chave primária.
Mas igualmente, em ambientes OLTP onde o PK é uma IDENTIDADE ou outra chave substituta, faz pouco sentido usar isso para a partição, já que o particionamento em números arbitrários normalmente não é muito útil. Em sistemas OLTP, você também tende a particionar mais por data (provavelmente não no PK), mas potencialmente também regionalmente ou por algum tipo de divisão organizacional (talvez no PK se você não estiver usando um substituto).
Mas não é uma exigência.
Tem que fazer parte de uma Chave Candidata, se não for parte da própria Chave Primária. Sendo a ideia, seu particionamento deve se alinhar com a chave primária.
Portanto, a resposta é sim, é preferível fazer parte do PK. Se não for outra chave, o que é igualmente bom o suficiente para ser um PK.