Naming convention for unique constraint

Question

Naming conventions are important, and primary key and foreign key have commonly used and obvious conventions (PK_Table and FK_Table_ReferencedTable, re

Answer 1

My naming convention for indices and constraints:

• Primary key. _PK
• Unique index/constraint. _AK{xx}
• Non-Unique index. _IX{xx}
• Check constraint. _CK{xx}
• Default constraint. _DF{xx}
• Foreign key constraint. _FK{xx}

Where {xx} is a 2-digit sequence number, starting at 01 for each constraint type per table. Primary key doesn't get a sequence number since there can be only one. The 2-char alpha suffix meanings are:

• PK: Primary Key
• AK: Alternate Key
• FK: Foreign Key
• IX: IndeX
• CK: ChecK
• DF: DeFault

I generally want to group metadata/system catalog data by the controlling object rather than by object type.

Answer 2

My thinking is it isn't a key: it's a constraint.

It could be used as a key of course, and uniquely identifies a row, but it isn't the key.

An example would be that the key is "ThingID", a surrogate key used in place of ThingName the natural key. You still need to constrain ThingName: it won't be used as a key though.

I'd also use UQ and UQC (if clustered).

You could use a unique index instead and go for "IXU". By the logic employed, an index is also a key but only when unique. Otherwise it's an index. So then we'd start with IK_columnname for unique indexes and IX_columnname for non-unique indexes. Marvellous.

And the only difference between a unique constraint and a unique index is INCLUDE columns.

Edit: Feb 2013. Since SQL Server 2008, indexes can have filters too. Constraints can not

So, it comes down to one of

• stick with UQ as per the rest of the SQL-using planet
• use IK for unique indexes (IKC for clustered too) to be consistent...

Answer 3

I use UQ. The K in UK makes me think of K as it's used in PK and FK. Well, after I think of United Kingdom anyways; ironic that this should be a prefix for UNIQUE when UK brings up so many other associations =)