I would see benefit in having a filtered INDEX as the target of an FK. I have run into such situations before.

For example, let’s say i have a system that has products, and imports information from another system that uses their own ids on a subset of products.

Product(MyId PK, Their_Id UNIQUE filter out NULLs);
Product_Info_From Other_System(Their_Id, info….)

I can modify the data on input to use our ids. However, if i want to keep the data as i get it, an FK to Their_Id would be nice. But, as they only have a subset of the products, i will have many NULLs in that COLUMN.

[CODE]create table t1
(c1 int,
c2 int)
go
create unique index i1 on dbo.t1
(c1)
where c1 is not null
go
create table t2
(c1 int constraint fk_t2_t1 foreign key references t1(c1))
go

/*
Msg 1776, Level 16, State 0, Line 1
There are no primary or candidate keys in the referenced table ‘t1′ that match the referencing column list in the foreign key ‘fk_t2_t1′.
Msg 1750, Level 16, State 0, Line 1
Could not create constraint. See previous errors.
*/[/CODE]

I like the idea of being able to use that as a candidate index. I’ve submitted this as a [A href="https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=498009"]connect item [/A]. The more people that vote for it the better the chance that they will implement it in the next release (or the one after that).