企业网站模板 下载 免费,高端企业网站建设核心,成都必去景点排名,wordpress指定目录文章文章目录 简介数据表的常见约束设计数据表的原则参考文献 简介
DDL中常用的功能是增删改#xff0c;分别对应的命令是create、drop和alter。
执行DDL的时候#xff0c;不需要commit#xff0c;就可以完成执行任务。
下面是MySQL里的一个典型的表创建语句#xff1a;
DR… 文章目录 简介数据表的常见约束设计数据表的原则参考文献 简介
DDL中常用的功能是增删改分别对应的命令是create、drop和alter。
执行DDL的时候不需要commit就可以完成执行任务。
下面是MySQL里的一个典型的表创建语句
DROP TABLE IF EXISTS player;
CREATE TABLE player (player_id int(11) NOT NULL AUTO_INCREMENT,team_id int(11) NOT NULL,player_name varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,height float(3, 2) NULL DEFAULT 0.00,PRIMARY KEY (player_id) USING BTREE,UNIQUE INDEX player_name(player_name) USING BTREE
) ENGINE InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci ROW_FORMAT Dynamic;注意数据类型里的int(11)表示整数类型其显示长度为11所以括号里面的数字11表示的是最大有效显示长度与类型包含的数值范围大小无关。
varchar(255)也是一样显示最大长度是255。
而Decimal(a,b)中a代表整数部分和小数部分加起来的最大位数b代表小数位数。如Decimal(8, 2)表示精度为8位整数加小数位最多为8位小数位为2位的数据类型。
排序规则是utf8_general_ci表示大小写不敏感如果设置为utf8_bin表示大小写敏感。
我们对player_name字段设置了唯一索引。也可以设置普通索引NORMAL INDEX。两者的区别在于唯一索引对字段添加了唯一性约束。
在索引方式上可以选择BTREE或者HASH这里我们用了BTREE即USING BTREE。
需要注意MySQL 在 Linux 的环境下数据库名、表名、变量名是严格区分大小写的而字段名是忽略大小写的。而 MySQL 在 Windows 的环境下全部不区分大小写。
数据表的常见约束
主要分为主键约束、外键约束和字段约束三大类。
主键是用来唯一标识一条记录其不能重复且不能为空一个数据表的主键只能有一个可以是一个字段也可以是由多个字段复合组成。
外键确保了表与表之间引用的完整性。一个表的外键对应另一张表的主键。外键可以是重复的也可以是空的。
字段约束
唯一性约束。表明字段的值在表中是唯一的主键默认具有唯一性约束和非空约束。NOT NULL约束。字段不应为nullDEFAULT。表明了字段的默认值。如DEFAULT 0.0CHECK约束。检查特定字段取值范围的有效性check约束的检查结果不能为FALSE比如我们对身高字段height做check约束即CHECK(height0 and height3);
设计数据表的原则
教程里提出了一个三少一多原则了解下就行相当于是理想派理论并不适用于当下
数据表的个数越少越好
RDBMS核心在于实体和联系的定义数据表越少说明实体和联系设计的越简洁。
数据表中的字段越少越好
字段数量越多数据冗余的可能性就越大。保持字段数量少各个字段间相互独立而不是某个字段的取值可以由其他字段计算出来。当然这只是个相对概念我们通常会在数据冗余和检索效率中进行平衡。
数据表中的联合主键的字段个数越少越好
因为联合主键的字段数量越多占用的索引空间就越大还会增加表使用时的理解难度。
使用主键和外键越多越好
主键和外键越多说明表之间的关系越多证明这些实体之间的冗余度越低利用度越高。在保证了各表独立性的前提下还提升了相互之间的关联使用率。
所以这里的三少一多原则核心就是简单可复用。
简单就是用更少的表、更少的字段、更少的联合主键字段来完成数据表的设计。
可复用是通过主键、外键的使用来增量表之间的复用率。
当然以上原则并不是绝对的在生产场景下很多时候我们需要牺牲数据的冗余度来换取数据处理的效率即以空间换时间。
而且关于是否使用外键是很有争议的。
外键本身的存在是为了保证数据的强一致性比如说可以配合级联更新自动更新删除关联的记录。
但其实我们完全可以不用外键而是在业务层来保证数据的一致性。当然会增加业务逻辑和数据之间的耦合。
但是对超大型的数据应用场景来讲在存在外键的情况下大量的插入、更新和删除记录会额外增加过多的开销尤其是在高并发、水平拆分、分库的情况下。因为每次更新数据都需要检查另外一张表的数据也很容易造成死锁。所以大型项目一般会取消外键来提高效率。
互联网公司一般推荐尽量少用或不用外键比如阿里的Java开发规范里也明确指出“不得使用外键与级联一切外键概念必须在应用层解决”以及外键与级联更新适用于单机低并发不适合分布式、高并发集群。级联更新是强阻塞存在数据库更新风暴的风险。外键也会影响数据的插入速度。
总结来看个人的小项目可以上上外键大型项目还是算了太过影响数据库的性能。
评论里有个很有意思“一般在业务层实现外键约束。学院派才喜欢瞎折腾什么外健触发器存储过程还扯出一大堆好的理由出来。事实上工程的主要复杂度往往来源于变化以及规模。 所以各个子母块之间耦合越小越好。存储中间件就安心的做好自己存储的那一块即可。没有必要一个存储中间件天天操着业务如何处理的心”。感觉说的很有道理。
参考文献
04丨使用DDL创建数据库数据表时需要注意什么
