表与表之间的约束不能同名，一个数据库中的约束不允许重名

专注，勤学，慎思。戒骄戒躁，谦虚谨慎

just do it

导航

• 博客园
• 首页
• 新随笔
•  
• 订阅
• 管理

统计

• 随笔 - 130
• 文章 - 0
• 评论 - 260
• 引用 - 0

随笔分类(132)

• ETL
• MongoDB(3)
• MySQL 8.0(3)
• MySQL备份还原(2)
• MySQL高可用(2)
• MySQL管理(22)
• MySQL基础(11)
• MySQL体系结构(4)
• MySQL优化(4)
• PowerShell
• Python(4)
• Redis(9)
• SQL Server 管理(15)
• SQL Server 基础(9)
• SQL Server 权限(2)
• SQL Server 优化(22)
• T-SQL(10)
• Zabbix(1)
• 工作随想
• 其他(1)
• 数据库设计(6)
• 死锁(2)

随笔档案(130)

• 2019年1月 (2)
• 2018年12月 (1)
• 2018年11月 (3)
• 2018年10月 (4)
• 2018年9月 (7)
• 2018年8月 (4)
• 2018年7月 (3)
• 2018年6月 (8)
• 2018年5月 (5)
• 2018年4月 (1)
• 2018年3月 (2)
• 2018年2月 (1)
• 2018年1月 (3)
• 2017年11月 (6)
• 2017年10月 (2)
• 2017年9月 (5)
• 2017年8月 (5)
• 2017年7月 (9)
• 2017年6月 (8)
• 2017年5月 (9)
• 2017年4月 (8)
• 2017年3月 (6)
• 2017年2月 (2)
• 2017年1月 (2)
• 2016年12月 (3)
• 2016年11月 (3)
• 2016年10月 (4)
• 2016年9月 (4)
• 2016年8月 (1)
• 2016年7月 (2)
• 2016年6月 (2)
• 2016年5月 (1)
• 2016年4月 (2)
• 2016年3月 (1)
• 2015年9月 (1)

文章分类

• oracle
• sqlserver
• 其他

最新评论

• 1. Re:MySQL执行计划extra中的using index 和 using where using index 的区别
• @snowfox09出现Using where Using index并不一定会发生回表，比如一下case索引是create index idx_userid_order_id_createdate ......
• --MSSQL123
• 2. Re:MySQL执行计划extra中的using index 和 using where using index 的区别
• 你好，请问Using where Using index这种情况是不是意味着会发生回表或者表扫描呢，从而性能上其实也是不高的呢？谢谢！
• --snowfox09
• 3. Re:SQLServer中的执行计划缓存由于长时间缓存对性能造成的干扰
• 666
• --小小小蘑菇
• 4. Re:TIMESTAMP类型字段在SQL Server和MySQL中的含义和使用
• 以前还真没有研究过这些细节，只有一次发现SQL Server的TIMESTAMP类型并非时间戳。
• --潇湘隐者
• 5. Re:SQL Server并发操作单个表时发生在page页面级的死锁
• @潇湘隐者确实，可能真正维护数据库处理死锁的，折腾过几次之后都有这种感觉，尽可能选择一个代价相对较小又比较快的处理方式来解决。...
• --MSSQL123

SQL Server中有关约束（constraint）的一些细节

本文出处：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的方式来定义，如果是临时表，禁止定义命名约束。

分类: T-SQL,数据库设计

好文要顶 关注我 收藏该文  

MSSQL123
关注 - 139
粉丝 - 161

+加关注

1

发表评论

« 上一篇：MySQL InnoDB内存压力判断以及存在的疑问
» 下一篇：MySQL执行计划extra中的using index 和 using where using index 的区别

posted on 2017-08-12 15:27 MSSQL123 阅读(2259) 评论(0) 编辑 收藏