A chave de partição também precisa fazer parte da chave primária?

Estou particionando uma tabela com base em uma coluna que não é uma chave primária? Hoje, li algumas informações conflitantes sobre se a coluna da partição deve fazer parte da chave primária. Meu intestino diz que não, mas não tenho 100% de certeza. Então perguntas ...

A coluna da partição deve fazer parte do primário? É recomendado de uma maneira ou de outra?
Preciso criar um índice para a chave da partição ou o DBMS o faz automaticamente por conta própria?

— AngryHacker
fonte

Respostas:

De modo nenhum.

Um dos cenários mais comuns para particionamento é usar um campo de data totalmente não relacionado ao seu PK.

Por exemplo, se você tiver uma tabela Orderscom o campo OrderDate, provavelmente particionará com base no mês e ano de OrderDate.

Quando os registros expiram e não são mais relevantes, você pode mover essas partições para uma tabela ou banco de dados de arquivamento, para que não sejam mais processadas.

O particionamento funcionará com praticamente qualquer campo, mas, para que funcione BEM, os campos em que você particiona devem ser usados na maioria, se não em todas, de suas consultas. Se você não incluir as chaves de partição, você terá essencialmente uma varredura cara de tabela, que abrange várias tabelas (partições).

EDITAR

Para a parte 2, acho que a resposta também não é. A chave da partição é usada para determinar em qual partição colocar a linha, mas não acho que um índice seja mantido. No entanto, pode haver estatísticas no back-end.

— JNK
fonte

Sei que isso é antigo, mas isso me levou a um caminho errado, então pensei em comentar para os outros. A coluna Partition deve estar na chave Primary se você deseja usar as habilidades SWITCH do recurso Partition. Se não estiver na chave primária, você receberá este erro: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Concordo com @Vaccano

— san

Além da resposta de 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 da captura instantânea de uma tabela de fatos geralmente é a coluna da partição e a primeira coluna na chave primária.

Mas igualmente, em ambientes OLTP em que o PK é uma IDENTIDADE ou outra chave substituta, faz pouco sentido usá-lo para a partição, pois a partição em números arbitrários normalmente não é muito útil. Nos sistemas OLTP, você também costuma particionar 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 é um requisito.

— Cade Roux
fonte

Bem, um monte de coisas não é um requisito. Mesmo a indexação não é um requisito! Para fazer sentido funcionalmente, o particionamento deve ser feito na coluna principal de uma chave candidata. Caso contrário, como o arquiteto do aplicativo usaria a tabela?

— srini.venigalla

@ srini.venigalla Esse é um caso comum, mas outro caso comum (igualmente?) é particionar algo que não faz parte de uma chave primária ou candidata - porque o particionamento é frequentemente usado para arquivamento, uma data de validade pode ser uma boa opção de partição. Mas não há nada que implique que possa fazer parte de uma chave. O particionamento é um recurso de baixo nível, bastante genérico e há pelo menos dois padrões de uso distintos e conflitantes aqui, ambos com práticas recomendadas legítimas.

— Cade Roux

Ele deve fazer parte de uma Chave Candidata, se não 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, que é igualmente boa o suficiente para ser um PK.

— srini.venigalla
fonte

Nunca ouvi falar da chave do candidato. Como alguém o especifica na instrução da tabela Create / Alter?

— AngryHacker

Chave Candidata é apenas outra chave qualificada para ser uma Chave Primária. Por exemplo, ID é a chave primária. Mas na mesma tabela, se outra coluna para por exemplo. PERSON_ID também pode identificar exclusivamente uma linha, chamada Chave do Candidato. As 2ª e 3ª regras de normalização também devem se aplicar a todas as chaves candidatas.

— 11789 srl.venigalla

Entendido. E a segunda parte da minha pergunta?

— AngryHacker 10/07/12

O mesmo que qualquer outro índice. exemplo: CREATE INDEX IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— 11789 src.venigalla

Isso é absolutamente incorreto. Você pode particionar em muitos campos que não estão relacionados à PK, como OrderDate. Você tem alguma coisa para fazer backup de suas reivindicações?

— JNK