不知是最近几天休息不好的原因，还是作息不够规律。
今天开始学这一篇的时候，已经十一点五十了。太过依赖某一样事物的时候，可能会产生逃离感。所以现在代码、项目、服务，都在讲可插拔，可移植，可开放API接口。
终于讲到这一课，高级SQL特性，一听就是一篇全是理论的课程。
目录
22.1 约束
经过多个版本的更新迭代，SQL已经变得越来越强了。能给用户使用者都带来许多高级的数据处理技术，这里我理解高级就是抽象化，已经不再是停留在数据的简单读取这个层面。
从关联表和引用完整性开始讲，关系型数据库存储分解为多个表的数据，每个表存储相应的数据，我们通过键建立了一表到另一表的引用，也应运而生引用完整性（referential integrity）这样的术语。
对于关系数据库设计，需要对插入数据进行判断是否合法，而这就需要我们设计一种方法用来保证插入表的就是合法的。比如：如果Order表来存储订单信息，OrderItems表存储订单详细内容，按照常理逻辑来说，应该保证OrderItems中引用的任何订单ID都存在于Orders中。类似地，在Orders表中引用的任意顾客必须存在于Customers表中。
居然零点了，在有点生气的情绪中，睡去吧。
明日复明日。
刻意练习，每日精进。
20200520
补充昨日的课程，今日情绪平复。又觉得自己可以了，回家摊着泡脚洗衣服收拾房间，大概是一个成年人的所有活动吧。看到两张很有意思的图，一张稍微修改一下作为朋友圈背景图，另一张本来想发朋友圈，想想止住了。快乐留在角落，并不因为传播而扩散。
昨天说到高级SQL特性，只学到了约束，今天可以稍微熬一熬，明天不用早起洗漱，精力也还好没有那么耷拉眼皮。
那么从回顾约束开始说起，约束是为了保证插入表中的数据是合法的，起码在逻辑上时走得通的，那么其他办法例如用插入前进行一些检查，去相关表中执行SELECT，保证所有值合法并存在再进行插入行不行呢？书上建议我们不要这样操作，因为：
不能保证所有客户端层面实现这些规则，这样很难保证数据库完整性；
执行UPDATE和DELETE操作时，就也得实施这些规则了；
再就是执行客户端检查是非常耗时的，而DBMS执行这些检查会相对高效。
那么，书上给约束（constraint）下了一个定义：“管理如何插入或处理数据库数据的规则”。
DBMS通过在数据库表上施加约束来实现引用完整性，大多数的约束在表定义中就定义了，联系表创建时定义表，表从出生起，就规定了哪些事情可做，哪些事情不可做。
注意表在不同DBMS
最低0.47元/天 解锁文章
250
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
