How do I have a check constraint that refers to another table?

Question

I have the following tables in a SQL Server 2008 db:

• tblItem, which has an ItemID field;

• tblGoodItem, which also has an ItemID field, and has a foreign key pointing to tblItem;

• tblBadItem, which also has an ItemID field, and also has a foreign key pointing to tblItem.

An item cannot be both a good item and a bad item; it must either be the one or the other. However, whether the item is good or bad, it must be an item.

My question is this: how do I add a constraint to the ItemID fields in both tblGoodItem and tblBadItem so that an ItemID value cannot exist in both tables?

I've read some replies in Stack Overflow on similar questions, and I'm thinking of this solution:

• Create a view vwItem which joins tblGoodItem on tblBadItem on ItemID.

• Write a UDF fnItem which does a query on vwItem to see how many records exist in the view.

• Have a constraint which calls fnItem and verifies that the value returned is 0.

Is this best idea? Does anyone have a better idea?

Solution 1

Add a column tblItem.ItemType column. This column can have only one value on any given row (obviously). Add a unique constraint over ItemID,ItemType.

Now the trick: few people remember this, but a foreign key can reference the columns of a unique constraint.

CREATE TABLE tblItem (
  ItemID INT PRIMARY KEY,
  ItemType CHAR(1),
  UNIQUE KEY (ItemID, ItemType)
);

CREATE TABLE tblGoodItem (
  ItemID INT PRIMARY KEY,
  ItemType CHAR(1),
  CHECK (ItemType='G')
  FOREIGN KEY (ItemID, ItemType) REFERENCES tblItem(ItemID, ItemType) 
);

CREATE TABLE tblBadItem (
  ItemID INT PRIMARY KEY
  ItemType CHAR(1),
  CHECK (ItemType='B')
  FOREIGN KEY (ItemID, ItemType) REFERENCES tblItem(ItemID, ItemType) 
);

If you constrain ItemType in each of the child tables to a fixed value, then a given row in tblItem can be referenced by only one child table.

It's a three-step process to change an item from good to bad, though:

1. DELETE row from tblGoodItem
2. UPDATE row's ItemType in tblItem
3. INSERT row in tblBadItem

Solution 2

You can't use a SELECT statement in a CHECK Constraint - thats not really what they were designed for.

I think your best option would be to write a UDF pass in the ItemId and check if it exists. For this scenario it really is the easiest option.

I've added some test data and an example function.

CREATE FUNCTION dbo.fn_CheckItems(@itemId INT) RETURNS BIT

AS BEGIN

DECLARE @i INT,
        @rv BIT


SET @i = 0

IF (SELECT COUNT(*) FROM tblBadItem WHERE ItemId = @ItemId) > 0
BEGIN
SET @i = 1
END


IF (SELECT COUNT(*) FROM tblGoodItem WHERE ItemId = @ItemId) > 0
BEGIN
SET @i = @i + 1
END

IF (@i > 1)
BEGIN
    SET @rv = 1
END
ELSE
BEGIN
    SET @rv =0
END


RETURN @rv

END
GO

CREATE  TABLE tblItem (
  ItemID INT IDENTITY(1,1) PRIMARY KEY,
  DateAdded DATETIME
)
GO

CREATE TABLE tblGoodItem (
  ItemID INT PRIMARY KEY,
  CHECK (dbo.fn_CheckItems(ItemId) = 0)

)
GO

CREATE TABLE tblBadItem (
  ItemID INT PRIMARY KEY,
  CHECK (dbo.fn_CheckItems(ItemId) = 0)
)
GO

INSERT INTO tblItem (DateAdded)
VALUES (GETDATE())

INSERT INTO tblGoodItem(ItemID)
SELECT ItemId FROM tblItem

--This statement will fail as the ItemId is already in GoodItems
INSERT INTO tblBadItem(ItemID)
SELECT ItemId FROM tblItem


DROP TABLE tblItem
DROP TABLE tblGoodItem
DROP TABLE tblBadItem
DROP FUNCTION dbo.fn_CheckItems

Solution 3

get rid of tblGoodItem and tblBadItem and make a new table with a ItemType="G" or "B" and put an unique index or key on ItemID, then no constraint is needed on tblItem.

Solution 4

I'm probably not understanding your business requirements here but why do you wish to have a separate table for Good and Bad items? Are these not abstractions of the same thing?

Why not use an isBadItem flag or more specifically an itemConditionStatus column.

Solution 5

In tblItem, add itemType column. Have a check constraint to make sure that itemType is either good or bad. Create a unique constraint on (ItemID, itemType )

Add itemType column to both bad and good items tables. Have a check constraint to make sure that itemType is good in good table, and bad in bad table.

View more solutions

Comments

[Tola Odejayi]

No can do, I'm afraid. Good items have some properties that bad items don't have, and vice versa.

[A-K]

you beat me by a few seconds.

[codingbadger]

@AlexKuznetsov - Could you elaborate as to why this will not work. I have created a test and it works fine?

[Tola Odejayi]

I like this idea a lot. No need to worry about changing from bad to good - in fact, I specifically don't want such change to happen.

[KM.]

if there are just a few, under 10 differences or so, then I's still combine them, make them allow NULL and add a check constraint to require them based on the Type column

[A-K]

my apologies, I was wrong. However, such UDFs are very slow, and if you use snapshot isolation you may sporadically get wrong results under concurrency.

[codingbadger]

@AlexKuznetsov - no problem. I must admit I haven't used this whilst using snapshot replication so I couldn't disagree or agree with that.