question

There isn't really a proper explanation other than "that's the way they originally implemented it and they don't want to break applications that now depend upon that behaviour." There is several years' worth of lively debate on just this topic over on connect (apparently, allowing multiple nulls would be compliant with the various SQL standards) - [ https://connect.microsoft.com/SQLServer/feedback/details/299229/change-unique-constraint-to-allow-multiple-null-values][1] It also turns out that two null values *can* be the same in SQL Server; more of that non-ansi compliance trouble... If you set ansi_nulls off, null values can be compared using the = operator - [ http://msdn.microsoft.com/en-us/library/ms188048.aspx][2] As long as SQL Server unique constraints don't have a strict ansi implementation, they need to limit the number of null values so the constraint behaves the same regardless of ansi settings. [1]: https://connect.microsoft.com/SQLServer/feedback/details/299229/change-unique-constraint-to-allow-multiple-null-values [2]: http://msdn.microsoft.com/en-us/library/ms188048.aspx