[完结11章]技术大牛成长课,从0到1带你手写一个数据库系统

学习地址1：https://pan.baidu.com/s/1OWDu5fNq_BXRUbLGrxzpJw 提取码：tjty 学习地址2：https://share.weiyun.com/Tp6ewDIJ 密码：6crcwd 今天跟大家交流一下关于开发一款数据库系统的相关事宜，从零开始，手把手带着大家一步步去实现这个功能，希望对大家有所帮助。 数据库系统是为适应数据处理的需要而发展起来的一种较为理想的数据处理系统，也是一个为实际可运行的存储、维护和应用系统提供数据的软件系统，是存储介质 、处理对象和管理系统的集合体。 数据库系统DBS（Data Base System，简称DBS）通常由软件、数据库和数据管理员组成。其软件主要包括操作系统、各种宿主语言、实用程序以及数据库管理系统。数据库由数据库管理系统统一管理，数据的插入、修改和检索均要通过数据库管理系统进行。数据管理员负责创建、监控和维护整个数据库，使数据能被任何有权使用的人有效使用。数据库管理员一般是由业务水平较高、资历较深的人员担任。 无论你是数据库内核研发、DBA、还是后端研发，能够手写一套自己的数据库系统，都是你突破技术发展瓶颈的有效途径。本课程将带你从架构设计 ，原理剖析，再到源码的实现，手把手带你构建一套完整的数据库系统，让你深度掌握数据库底层，及更多数据库高端技术，具备解决大量生产级数据库问题的能力，助力成为高端技术人才！ 从数据库架构设计到功能实现，吃透底层原理，解决大量生产级问题 具备从0到1数据库系统的架构设计能力 从需求分析，系统分析，到系统架构设计，以及面向未知故障场景防御式编程，灵活运用设计模式，全面深入理解数据库系统架构 深度掌握数据库底层原理及系统性方法论 掌握SQL语法解析、语义解析原理，数据库如何生成执行计划，数据库底层存储机制、事务管理机制，C/S架构网络服务，综合性提升数据库运维、调优能力 提升大量生产级数据库问题高效解决能力 深入掌握数据库索引调优思路、瓶颈点，如何快速定位线上问题，深入挖掘针对数据库的面试题，知其然更知其所以然，有效突破你的疑难杂症问题解决能力。 1.5数据库系统模式 开发人员角度（内部的系统结构）：三级模式结构 用户角度（外部的系统结构）：单用户结构、主从式结构、分布式结构 模式：数据库中全体数据的逻辑结构和特征的描述，仅涉及型的描述，不涉及具体的值 实例：模式的一个具体的值 模式是相对稳定的，实例是相对变动的 1.6数据库系统的三级模式结构 数据库由外模式、模式和内模式三级构成 模式（schema）：也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个模式 外模式：也称子模式或用户模式，他是数据库用户能够看到和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。一个数据库可以有多个外模式。一个应用只能用一个外模式，一个外模式可以共多个应用程序使用。 内模式：也称存储模式，描述数据物理结构和存储方式。一个数据库只有一个内模式 1.7数据库的二级映像功能 为了能在系统内部实现三个抽象层次的联系和转换，数据库管理系统在这三级模式之间提供了两层映像：外模式/模式映像、模式/内模式映像 外模式/模式映像：模式描述的是数据的全局逻辑结构，外模式描述的是数据局部逻辑结构。一个模式可以有多个外模式。对每一个外模式有一个映像描述对应关系，这些映像定义包含在外模式的描述中 模式改变，管理员改变该映像，使外模式保持不变。应用程序不用改变，保证了数据与程序的逻辑独立性 模式/内模式：该模式映像是唯一的。定义了数据全局逻辑结构和存储结构之间的对应关系。 数据存储结构改变时，改变该映像，可以使模式、应用程序保持不变。保证了数据与程序的物理独立性。 因为添加角色和修改角色信息共用同一个弹窗页面，弹窗页面的代码我们都已经写完了，所以我们要回到角色管理页面编写JS代码来显示弹窗页面，然后传入要修改的角色ID，让弹窗页面去查询该角色的信息。 <select id="searchCanDelete" resultType="boolean"> SELECT IF( SUM( temp.users ) > 0, FALSE, TRUE ) AS result FROM ( SELECT COUNT( u.id ) AS users FROM tb_role r JOIN tb_user u ON JSON_CONTAINS ( u.role, CONVERT ( r.id, CHAR ) ) WHERE r.id IN <foreach collection="array" open="(" separator="," close=")" item="one"> #{one} </foreach> GROUP BY r.id ) temp </select> <delete id="deleteRoleByIds"> DELETE FROM tb_role WHERE id IN <foreach collection="array" open="(" separator="," close=")" item="one"> #{one} </foreach> AND systemic=FALSE </delete> 如果我们把上面的SQL语句查询的结果当做一张临时表，统计求和是否大于零。如果大于零，说明你要删除的这些角色中，有关联用户的角色。大家仔细想想，用户在前端页面勾选了若干角色，想要删除这些角色。后端只要盘判定出这些角色，无论哪一个只要存在关联的用户，那么这些要删除的角色一律不许删除。除非我们统计求和的结果是零，说明这些要删除的角色都没有关联用户，这些角色允许删除。 public class RoleController { …… @PostMapping("/deleteRoleByIds") @Operation(summary = "删除角色记录") @SaCheckPermission(value = {"ROOT", "ROLE:DELETE"}, mode = SaMode.OR) public R deleteRoleByIds(@Valid @RequestBody DeleteRoleByIdsForm form) { int rows = roleService.deleteRoleByIds(form.getIds()); return R.ok().put("rows", rows); } } 我们首先看一下模型层定义的变量，除了有查询条件之外，还有与分页相关的变量，以及保存勾选的部门记录的变量，最后是表单验证的规则。总体上来看，跟用户管理页面的模型层差不多。 data: function() { return { dataForm: { deptName: null }, dataList: [], pageIndex: 1, pageSize: 10, totalCount: 0, dataListLoading: false, dataListSelections: [], addOrUpdateVisible: false, dataRule: { deptName: [ { required: false, pattern: '^[a-zA-Z0-9\u4e00-\u9fa5]{1,10}$', message: '部门名称格式错误' } ] } }; }, 我们声明查询按钮点击事件对应的回调函数，写完这个函数大家就可以运行前后端项目，测试一下数据的查询和分页效果。 searchHandle: function() { this.$refs['dataForm'].validate(valid => { if (valid) { this.$refs['dataForm'].clearValidate(); if (this.dataForm.deptName == '') { this.dataForm.deptName = null; } if (this.pageIndex != 1) { this.pageIndex = 1; } this.loadDataList(); } else { return false; } }); },