La clé de partition doit-elle également faire partie de la clé primaire?

Je partitionne une table en fonction d'une colonne qui n'est pas une clé primaire? J'ai lu aujourd'hui des informations contradictoires sur la question de savoir si la colonne de partition doit faire partie de la clé primaire. Mon instinct dit non, mais je ne suis pas sûr à 100%. Alors des questions ...

La colonne de partition doit-elle faire partie du primaire? Est-il recommandé dans un sens ou dans l'autre?
Dois-je créer un index pour la clé de partition, ou le SGBD le fait-il automatiquement de lui-même?

— AngryHacker
source

Réponses:

Pas du tout.

L'un des scénarios de partitionnement les plus courants consiste à utiliser un champ de date, qui n'a aucun lien avec votre PK.

Par exemple, si vous avez une table Ordersavec le champ, OrderDatevous partitionnerez probablement en fonction du mois et de l'année de OrderDate.

Lorsque les enregistrements expirent et ne sont plus pertinents, vous pouvez déplacer ces partitions vers une table d'archives ou une base de données afin qu'elles ne soient plus traitées.

Le partitionnement fonctionnera avec à peu près n'importe quel champ, mais pour qu'il fonctionne BIEN, le ou les champs sur lesquels vous partitionnez doivent être utilisés dans la plupart, sinon la totalité, de vos requêtes. Si vous n'incluez pas vos clés de partition, vous obtiendrez essentiellement une analyse de table coûteuse qui s'étend sur plusieurs tables (partitions).

MODIFIER

Pour la partie 2, je pense que la réponse est également négative. La clé de partition est utilisée pour déterminer dans quelle partition mettre la ligne, mais je ne pense pas qu'un index soit maintenu. Il peut cependant y avoir des statistiques à l'arrière.

— JNK
source

Je sais que c'est vieux, mais cela m'a conduit sur une mauvaise voie, alors j'ai pensé que je commenterais pour les autres. La colonne de partition doit être dans la clé primaire si vous souhaitez utiliser les capacités SWITCH de la fonction de partition. S'il n'est pas dans la clé primaire, vous obtiendrez cette erreur: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Je suis d'accord avec @Vaccano

— san

En plus de la réponse de JNK, vous devriez probablement lire cet article qui traite de l'alignement des partitions de table et des partitions d'index.

Il existe de nombreux types de scénarios dans lesquels le schéma de partitionnement suit exactement la première colonne de la clé primaire - par exemple dans un scénario d'entrepôt de données où la date d'instantané d'une table de faits est généralement la colonne de partition ainsi que la première colonne de la clé primaire.

Mais également, dans les environnements OLTP où le PK est une IDENTITY ou une autre clé de substitution, cela n'a pas de sens de l'utiliser pour la partition, car le partitionnement sur des nombres arbitraires n'est normalement pas terriblement utile. Dans les systèmes OLTP, vous avez également tendance à partitionner le plus par date (probablement pas dans le PK), mais potentiellement aussi régionalement ou par une sorte de division organisationnelle (peut-être dans le PK si vous n'utilisez pas de substitut).

Mais ce n'est pas une exigence.

— Cade Roux
source

Eh bien, beaucoup de choses ne sont pas obligatoires. Même l'indexation n'est pas obligatoire! Pour avoir un sens fonctionnel, le partitionnement doit être effectué sur la première colonne d'une clé candidate. Sinon, comment l'architecte de l'application utiliserait-elle la table?

— srini.venigalla

@ srini.venigalla C'est un cas courant, mais un autre cas courant (également?) est de partitionner quelque chose qui ne fait pas du tout partie d'une clé primaire ou candidate - car le partitionnement est souvent utilisé pour l'archivage, une date d'expiration peut être un bon choix de partition. Mais rien n'implique que cela pourrait faire partie d'une clé. Le partitionnement est une fonctionnalité de bas niveau qui est assez générique et il y a au moins deux modèles d'utilisation distincts et conflictuels ici, qui ont tous les deux des meilleures pratiques légitimes autour d'eux.

— Cade Roux

Il doit faire partie d'une clé candidate s'il ne fait pas partie de la clé primaire elle-même. L'idée étant, votre partitionnement devrait s'aligner sur la clé primaire.

Donc, la réponse est oui, il est préférable de faire partie du PK. Sinon, une autre clé, qui est tout aussi bonne pour être un PK.

— srini.venigalla
source

Jamais entendu parler de la clé du candidat. Comment peut-on le spécifier dans l'instruction de création / modification de table?

— AngryHacker

La clé candidate n'est qu'une autre clé qualifiée pour être une clé primaire. Par exemple, l'ID est la clé primaire. Mais dans le même tableau, si une autre colonne, par exemple. PERSON_ID peut également identifier de façon unique une ligne, appelée clé candidate. Les 2e et 3e règles de normalisation devraient également s'appliquer à toutes les clés candidates.

— srini.venigalla

Compris. Et la 2e partie de ma question?

— AngryHacker

Identique à tout autre index. exemple: CREATE INDEX IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— srini.venigalla

C'est absolument incorrect. Vous pouvez partitionner sur de nombreux champs qui ne sont pas du tout liés au PK, tels que OrderDate. Avez-vous quelque chose pour étayer vos réclamations?

— JNK