Muss der Partitionsschlüssel auch Teil des Primärschlüssels sein?

Ich partitioniere eine Tabelle basierend auf einer Spalte, die kein Primärschlüssel ist. Ich habe heute widersprüchliche Informationen darüber gelesen, ob die Partitionsspalte Teil des Primärschlüssels sein muss. Mein Bauch sagt nein, aber ich bin nicht 100% sicher. Also Fragen ...

Muss die Partitionsspalte Teil der Primärspalte sein? Ist es so oder so zu empfehlen?
Muss ich einen Index für den Partitionsschlüssel erstellen oder führt das DBMS dies automatisch aus?

— AngryHacker
quelle

Antworten:

Keineswegs.

Eines der häufigsten Szenarien für die Partitionierung ist die Verwendung eines Datumsfelds, das in keiner Beziehung zu Ihrer PK steht.

Wenn Sie zum Beispiel eine Tabelle Ordersmit dem Feld haben OrderDate, würden Sie höchstwahrscheinlich nach Monat und Jahr partitionieren OrderDate.

Wenn Datensätze verfallen und nicht mehr relevant sind, können Sie diese Partitionen in eine Archivtabelle oder Datenbank verschieben, damit sie nicht mehr verarbeitet werden.

Partitionierung funktioniert mit so ziemlich jedem Feld, aber damit es GUT funktioniert, sollten die Felder, auf denen Sie partitionieren, in den meisten, wenn nicht allen Abfragen verwendet werden. Wenn Sie Ihre Partitionsschlüssel nicht angeben, erhalten Sie im Wesentlichen einen teuren Tabellenscan, der sich über mehrere Tabellen (Partitionen) erstreckt.

BEARBEITEN

Für Teil 2 denke ich , ist die Antwort auch nein. Der Partitionsschlüssel wird verwendet, um zu bestimmen, in welche Partition die Zeile eingefügt werden soll, aber ich glaube nicht, dass ein Index beibehalten wird. Es kann jedoch Statistiken im Back-End geben.

— JNK
quelle

Ich weiß, dass dies alt ist, aber es hat mich auf einen falschen Weg geführt, sodass ich dachte, ich würde für andere Kommentare abgeben. Die Partitionsspalte muss sich im Primärschlüssel befinden, wenn Sie die SWITCH-Funktionen der Partitionsfunktion verwenden möchten. Wenn es nicht im Primärschlüssel ist, erhalten Sie diese Fehlermeldung: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Ich bin mit @Vaccano einverstanden

— San

Zusätzlich zur Antwort von JNK sollten Sie wahrscheinlich diesen Artikel lesen, in dem das Ausrichten von Tabellenpartitionen und Indexpartitionen beschrieben wird.

Es gibt viele Arten von Szenarien, in denen das Partitionsschema genau der ersten Spalte des Primärschlüssels folgt - beispielsweise in einem Data-Warehouse-Szenario, in dem das Momentaufnahmedatum einer Faktentabelle in der Regel die Partitionsspalte sowie die erste Spalte des Primärschlüssels ist.

In OLTP-Umgebungen, in denen der PK eine IDENTITY oder ein anderer Ersatzschlüssel ist, ist es jedoch wenig sinnvoll, dies für die Partition zu verwenden, da die Partitionierung nach beliebigen Zahlen normalerweise nicht besonders nützlich ist. In OLTP-Systemen tendieren Sie auch dazu, am häufigsten nach Datum zu partitionieren (wahrscheinlich nicht in der PK), aber möglicherweise auch regional oder nach einer Art organisatorischer Aufteilung (möglicherweise in der PK, wenn Sie keinen Ersatz verwenden).

Aber es ist keine Voraussetzung.

— Cade Roux
quelle

Nun, eine ganze Menge Zeug ist keine Voraussetzung. Auch die Indizierung ist keine Voraussetzung! Um einen funktionellen Sinn zu ergeben, muss die Partitionierung in der ersten Spalte eines Kandidatenschlüssels erfolgen. Andernfalls wie würde der App-Architekt die Tabelle verwenden?

— srini.venigalla

@ srini.venigalla Das ist ein häufiger Fall, aber ein weiterer häufiger Fall (ebenso?) ist die Partitionierung auf etwas, das überhaupt nicht Teil eines Primär- oder Kandidatenschlüssels ist - da die Partitionierung häufig für die Archivierung verwendet wird, kann ein Ablaufdatum sein eine gute Wahl für Partitionen. Aber es gibt nichts, was impliziert, dass es Teil eines Schlüssels sein könnte. Partitionierung ist eine allgemeine Funktion auf niedriger Ebene, und es gibt mindestens zwei unterschiedliche und widersprüchliche Verwendungsmuster, die beide über legitime Best Practices verfügen.

— Cade Roux

Es muss Teil eines Kandidatenschlüssels sein, wenn es nicht Teil des Primärschlüssels selbst ist. Ihre Partitionierung sollte sich am Primärschlüssel ausrichten.

Die Antwort lautet also: Ja, es wird bevorzugt, Teil der PK zu sein. Wenn nicht ein anderer Schlüssel, der genauso gut ist, um ein PK zu sein.

— srini.venigalla
quelle

Noch nie von dem Kandidatenschlüssel gehört. Wie spezifiziert man es in der Create / Alter-Table-Anweisung?

— AngryHacker

Der Kandidatenschlüssel ist nur ein weiterer Schlüssel, der als Primärschlüssel qualifiziert ist. ID ist beispielsweise der Primärschlüssel. Aber in der gleichen Tabelle, wenn eine andere Spalte für z. PERSON_ID kann auch eine Zeile, die als Kandidatenschlüssel bezeichnet wird, eindeutig identifizieren. Die 2. und 3. Normalisierungsregel sollten auch für alle Kandidatenschlüssel gelten.

— srini.venigalla

Verstanden. Was ist mit dem 2. Teil meiner Frage?

— AngryHacker

Wie jeder andere Index. Beispiel: CREATE INDEX IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— srini.venigalla

Das ist absolut falsch. Sie können in vielen Feldern partitionieren, die überhaupt nicht mit der PK zusammenhängen, z OrderDate. Haben Sie irgendetwas, um Ihre Ansprüche zu stützen?

— JNK