We have a database where several tables are partitioned. The primary key (PK for brevity) for these tables is of the form
- transaction_date, id
Where transaction_date is the partitioning key, and id is a unique integer column. If we were not partitioning the table, then we would only use id as the PK.
We have several other tables which need foreign keys (FKs) to reference these partitioned tables. I cannot decide whether to use composite FKs, referencing both columns of the PK, or single column FKs, referencing the id column supported by a unique index.
Are there any advantages/disadvantages of either approach? So far the only factors I can think of (and I may even be wrong on these) are:
-
Single column FK: Reduces app development complexity.
-
Composite FK: Allows partition elimination when joining on FK columns.
Best Answer
ALL unique constraints involved in a partitioning scenario MUST have the partition column defined as part of the base index definition (subset of the index key) - (not merely an included column). In other words, you will not be able to create a unique constraint on just the
ID
column in this scenario.Set up a partition function and scheme.
Create a table with a
PRIMARY KEY
that references the partition scheme.Now, try to create a unique constraint on the partitioned table without specifying the partition column.
So, when you ask the question:
I'm afraid SQL Server has decided for you. You will have to define your FK's with both
TransactionDate
ANDID
.