Anche la chiave di partizione deve far parte della chiave primaria?

Sto partizionando una tabella basata su una colonna che non è una chiave primaria? Oggi ho letto alcune informazioni contrastanti sul fatto che la colonna della partizione debba far parte della chiave primaria. Il mio istinto dice di no, ma non ne sono sicuro al 100%. Quindi domande ...

La colonna della partizione deve essere parte del primario? È raccomandato in un modo o nell'altro?
Devo creare un indice per la chiave di partizione o il DBMS lo fa automaticamente da solo?

— AngryHacker
fonte

Risposte:

Affatto.

Uno degli scenari più comuni per il partizionamento è l'uso di un campo data, totalmente estraneo al tuo PK.

Ad esempio, se hai una tabella Orderscon il campo OrderDate, molto probabilmente partizionerai in base al mese e all'anno di OrderDate.

Quando i record scadono e non sono più rilevanti, è possibile spostare quelle partizioni su una tabella di archivio o su un database in modo che non vengano più elaborate.

Il partizionamento funzionerà praticamente con qualsiasi campo, ma per farlo funzionare BENE i campi su cui partizionare dovrebbero essere usati nella maggior parte, se non in tutte, delle tue query. Se non includi le tue chiavi di partizione, otterrai essenzialmente una costosa scansione delle tabelle che attraversa più tabelle (partizioni).

MODIFICARE

Per la parte 2, penso che anche la risposta sia no. La chiave di partizione viene utilizzata per determinare in quale partizione inserire la riga, ma non credo che venga mantenuto un indice. Tuttavia, potrebbero esserci delle statistiche nel back-end.

— JNK
fonte

So che questo è vecchio, ma mi porta su una strada sbagliata, quindi ho pensato di commentare per gli altri. La colonna Partizione deve essere nella chiave primaria se si desidera utilizzare le abilità SWITCH della funzione Partizione. Se non si trova nella chiave primaria si otterrà questo errore: Partition columns for a unique index must be a subset of the index key.

— Vaccano

Sono d'accordo con @Vaccano

— san

Oltre alla risposta di JNK, probabilmente dovresti leggere questo articolo che discute sull'allineamento delle partizioni di tabella e delle partizioni di indice.

Esistono molti tipi di scenari in cui lo schema di partizionamento segue esattamente la prima colonna della chiave primaria, ad esempio in uno scenario di data warehouse in cui la data dell'istantanea di una tabella dei fatti è in genere la colonna della partizione e la prima colonna della chiave primaria.

Allo stesso modo, negli ambienti OLTP in cui il PK è un'IDENTITÀ o un'altra chiave surrogata, ha poco senso usarlo per la partizione, dal momento che il partizionamento su numeri arbitrari non è normalmente terribilmente utile. Nei sistemi OLTP, si tende anche a partizionare per data più (probabilmente non nel PK), ma potenzialmente anche a livello regionale o per qualche tipo di divisione organizzativa (forse nel PK se non si utilizza un surrogato).

Ma non è un requisito.

— Cade Roux
fonte

Bene, un sacco di roba non è un requisito. Anche l'indicizzazione non è un requisito! Per avere un senso funzionale, il partizionamento deve essere eseguito sulla colonna principale di una chiave candidata. Altrimenti come dovrebbe usare la tabella l'architetto dell'app?

— srini.venigalla,

@ srini.venigalla Questo è un caso comune, ma un altro caso comune (ugualmente?) è quello di partizionare su qualcosa che non fa affatto parte di una chiave primaria o candidata - poiché il partizionamento è spesso usato per l'archiviazione, una data di scadenza può essere una buona scelta di partizione. Ma non c'è nulla che implichi che potrebbe essere parte di una chiave. Il partizionamento è una funzionalità di basso livello che è piuttosto generica e ci sono almeno due modelli di utilizzo distinti e contrastanti qui, entrambi con le migliori pratiche legittime intorno a loro.

— Cade Roux,

Deve essere parte di una chiave candidata se non parte della chiave primaria stessa. Essendo l'idea, il tuo partizionamento dovrebbe allinearsi con la chiave primaria.

Quindi la risposta è sì, si preferisce far parte del PK. Se non un'altra chiave, che è altrettanto buona per essere un PK.

— srini.venigalla
fonte

Mai sentito parlare della chiave del candidato. Come lo si specifica nell'istruzione di tabella Crea / Modifica?

— AngryHacker,

La chiave candidata è solo un'altra chiave qualificata come chiave primaria. Ad esempio, ID è la chiave primaria. Ma nella stessa tabella, se un'altra colonna per es. PERSON_ID può anche identificare in modo univoco una riga, che si chiama Candidate Key. Le regole di normalizzazione 2a e 3a dovrebbero valere anche per tutte le chiavi candidate.

— srini.venigalla,

Inteso. E la seconda parte della mia domanda?

— AngryHacker,

Come qualsiasi altro indice. esempio: CREATE INDEX IX_ProductVendor_VendorID ON Purchasing.ProductVendor (BusinessEntityID);

— srini.venigalla,

Questo è assolutamente errato. È possibile partizionare su molti campi che non sono affatto correlati al PK, come ad esempio OrderDate. Hai qualcosa per il backup dei tuoi reclami?

— JNK,