I’m using SQL Server 2008. I have a database table that looks like this (with unimportant columns ommitted):
CREATE TABLE [dbo].[ImageDocument_FaxProperties](
[FaxPropertyID] [int] PRIMARY KEY IDENTITY(1,1),
[Agent] [varchar](25) NULL,
[ParentImageDocumentId] [uniqueidentifier] NULL
)
I want to create a constraint where the same Agent can have multiple rows as long as the ParentImageDocumentIds are the same on each row, but an Agent cannot have rows with different ParentImageDocumentIds. I understand this isn’t a good table structure, but it’s legacy & I’m not allowed to change it. NULL ParentImageDocumentIds should be considered different.
For example:
PK Agent ParentImageDocumentId -This is ok
# person1 {D09C3900-0300} {.. other columns ..}
# person1 {D09C3900-0300} {.. other columns ..}
PK Agent ParentImageDocumentId -Check constraint prevents 2nd row insertion
# person1 NULL {.. other columns ..}
# person1 NULL {.. other columns ..}
PK Agent ParentImageDocumentId -Check constraint prevents 2nd row insertion
# person1 NULL {.. other columns ..}
# person1 {A13E5B21-93DE} {.. other columns ..}
PK Agent ParentImageDocumentId -Check constraint prevents 2nd row insertion
# person1 {D09C3900-0300} {.. other columns ..}
# person1 {A13E5B21-93DE} {.. other columns ..}
I’m wondering what’s the best way to write a constraint for this. A unique index on Agent won’t work, because they can sometimes have both. A unique on Agent, ParentImageDocumentId would allow them to have different GUIDs, which is not okay. A filtered index with “WHERE ParentImageDocumentId IS NULL AND Agent IS NOT NULL” will work to prevent double NULLs, but not different GUIDs or GUID & NULL.
Below are two working solutions, however I’m wondering if there’s a better way. An indexed schemabound view allows me to create a more complicated filtered index. An alternative was a table-level check constraint using a function, this should work, but adding the check constraint is SUPER SLOW. I’m guessing it’s re-running my function for every row in the table, but that should be unnecessary for adding a table-level constraint since the function is not checking a specific row. Is there a way around this? I’m leaning towards the indexed view, but wondered if there are alternatives (aside from change my table structure) & which alternative is the best.
Solution #1:
CREATE VIEW ImageDocument_FaxProperties_Assignments WITH SCHEMABINDING
AS
SELECT Agent, ParentImageDocumentId, COUNT_BIG(*) as numPages FROM dbo.ImageDocument_FaxProperties
WHERE Status IN ( 'PROC', 'LINKING' )
AND Agent IS NOT NULL
GROUP BY Agent, ParentImageDocumentId
GO
CREATE UNIQUE CLUSTERED INDEX [IDX_ImageDocument_FaxProperties_Assignments_Unique] ON [ImageDocument_FaxProperties_Assignments] (Agent)
GO
Solution #2:
CREATE FUNCTION ImageDocument_FaxProperties_Assignments_CheckConstraint() RETURNS BIT
AS
BEGIN
DECLARE @Result BIT = 0;
WITH Assignments AS
(SELECT Agent, DENSE_RANK() OVER (PARTITION BY Agent ORDER BY ParentImageDocumentId) AS assignmentNum
FROM dbo.ImageDocument_FaxProperties
WHERE Status IN ( 'PROC', 'LINKING' )
AND Agent IS NOT NULL
)
SELECT @Result = 1 FROM Assignments WHERE assignmentNum > 1
RETURN @Result
END
GO
ALTER TABLE [ImageDocument_FaxProperties]
ADD CONSTRAINT ImageDocument_FaxProperties_Assignments_Unique CHECK (dbo.ImageDocument_FaxProperties_Assignments_CheckConstraint() = 0)
The indexed view will be the better option of the two you propose.
This kind of logic in UDFs is inefficient (it is evaluated for each row) and difficult to get right. See for example the following posts