本文出处：http://www.cnblogs.com/wy123/p/7350265.html
（保留出处并非什么原创作品权利，本人拙作还远远达不到，仅仅是为了链接到原文，因为后续对可能存在的一些错误进行修正或补充，无他）
SQL Server 数据库中的约束（Constrint）是作用是为了保证数据库的完整性和一致性，可以建表的时候指定某个字段要符合某种约束，比如唯一性（或者主键）约束，非空约束，默认值约束等
对于具体的约束，可以分为主键（唯一键）约束，默认值约束，检查约束，外键约束等几类。
约束的创建方式
1，建表的时候指定
如下，可以在建表的时候指定某些字段满足某种约束。
2，以创建约束的方式指定
也即在建表的时候没有指定任何约束，在建表之后，以alter table的方式指定某些字段上的约束
对于Check或者Default约束，也可以事先定义出来规则（Rule），然后将规则绑定到对应表的字段
如下分别定义了一个check约束和默认值约束，然后将表的字段绑定到对应的约束，这样做的好处是对于某些复杂的约束，定义好约束之后就可以重用了
需要注意的是，对于Rule来说，NULL值是不与任何规则冲突的，
举个例子，如下，虽然把TestConstrint.Sex字段指定了规则Rule_Sex，如果Sex定义的是int，该字段写入数据的时候只能是0或者1，写入2是失败的，
但是往该字段写入null值是可以的，因为null与规则指定的（0,1）相比没有任何意义（或者没有任何结果）
约束的一些特点
对于建表的时候指定的未命名的约束，SQL Server会自动生成后缀随机的默认的约束名字，为了增加规范性，正常情况下是不允许这么写的，因为我们不希望看到数据库中一堆乱七八脏的命名
如果是指定约束的名字，看起来就规范多了。
如果是通过定义规则，然后绑定到表的情况下，通过SSMS的图形界面，是看不到约束展开之后的内容的（虽然这个约束是生效的）
数据库约束中那些不容易被注意的坑
约束看起来非常简单，不管是在建表的时候直接指定，或者是通过alter 表的方式增加约束，看起来都没有任何问题，条条大道通罗马，不过里面还是有一些小坑的。
一个数据库中的约束不允许重名。
也就是意味着，不同的表之间，或者表上与自定义约束之间，都不能存在同名的情况，包括主键约束（不能同名），检查约束（check），默认值约束等，都不能同名
约束的道理跟表一样，一个库的一个schema下中不能定义同名的表一个道理，一个库的一个schema下不能定义同名的约束一样。
现在也不难理解，为什么sqlserver默认生成的约束的名字，后面是一串随机字符了吧？
1，表与表之间的约束不能同名
2，表与自定义约束名之间不能同名。
当然有人会说，这有什么，定义的时候报错就知道了，还有更大的坑。
这里涉及到约束的另一种定义方法，建表的过程中指定命名的主键约束。
比如如下的定义临时表的脚本，看起来没有任何问题，也确实没有任何问题，
实际中遇到的一个开发人员的问题，编写的存储过程中定义了临时表，定义临时表的时候指定了命名的主键约束（可能是抄的物理表的定义方式），测试通过并发布到生产环境中，一切看起来非常正常。
发布之后测试了两把，也表现为正常，等到系统真正被用户使用的时候，部分用户反馈系统（涉及到这个功能的地方）偶尔会报错，时而正常，时而不正常（其实这种问题最难诊断的了）。
监控应用程序会发现，某个时间段之内，发现这个存储过程会不停地报错，错误原因就是“无法创建索引或者约束”
开发人员也很委屈，提交完代码之后，明明是测试通过了的，更可恶的是，偶尔会报错，大部分时间是正常的。
通过观察其代码，然后冷静下来想一想，也不难理解，数据库中的约束是不能同名的，当然临时表生存的临时库也不例外，
临时表用完就会自动销毁没有错，意味着如果所有的Session都是串行执行，这个完全没有问题。
但是一旦出现并发调用的情况，不同的Session会同时调用这个存储过程，
一旦并发调用这个存储过程，不同的Session会创建同一个名字的约束，铁定只有一个会成功，这么看，单线程测试正常，并发上来之后报错也就不难理解了。
总结：
为了保证数据库的完整性和一致性（外键，本为未涉及），可以使用约束来达到这个目的，但是约束本身有自己的某些规则和特点，它跟其他数据库对象并没有不同的，都不允许同一个schema下存在同名的对象。
如果没有按照其自身的某些规则来使用，就有可能造成某些潜在的问题。
为了规范约束的命名，在定义约束名字的时候，要严格遵循前缀+schema+tableName+columnName的方式来定义，如果是临时表，禁止定义命名约束。