Unique Constraint vs Unique Index

This MSDN article comparing the two is for SQL Server 2000: http://msdn.microsoft.com/en-us/library/aa224827(SQL.80).aspx

For most purposes, there's no difference - the constraint is implemented as an index under the covers. And though there's the ability to disable the constraint, it doesn't actually work in SQL Server.

It only matters if you want to tweak things like FILLFACTOR, etc for which way you want to implement the unique constraint.

SQL Server 2008+ added INCLUDE to provide more efficient covering indexes. Filtered indexes = unique constraint over a subset of rows/ignore multiple null etc.

They are not significantly different. When you create a unique constraint, SQL Server will automatically create a unique index for you.

With the syntax for creating an index, you may have better control defining a unique index to specify clustered/nonclustered, included columns, filegroup, index filtering (SqlSvr2008), etc.

A constraint is preferable in most cases because it expresses the intent of the uniqueness: it is a constraint. An index does not convey this intent.

As for manageability, the impact is minimal. You can manage the index (rebuild, reorg) as if it were created independently of the constraint. The only difference is that the constraint depends on the index, so to drop the index, you must also drop the constraint.

My two cents: I would use a constraint when I wanted to describe business logic and an index when I wanted to enhance performance. The fact that they can be implemented the same in a DBMS does not mean that the distinction between the reasons for defining these objects is not significant.