<未完成>数据库系统的基本概念和底层存储方式
数据的可持久化需求的抽象层次矛盾
为什么需要数据库?
绝大多数学校的程序设计课节课时或开课期间的实验课都会有一个工程实践,
一般是 XX 管理系统,
向刚刚学习程序设计的学生浅显地介绍实际工程中的一些应用(输入输出交互/控制流/数据处理/可持久化),
b 格高一点的如 gitlet
针对可持久化还会有对象的序列化/反序列化等介绍,
建立起对于可持久化数据的基本认知.
一个运行中的程序的实例(进程以及其中可能存在的多个线程)
实质上是一段内存中的数据(代码区/数据区, 堆/栈, 环境和参数),
例如局部变量或者动态分配的内存,
而这些都是不可持久化的数据,
在程序关闭后大部分数据会被操作系统清理.
此时如果想可持久化某些数据使得下次程序启动仍然可以打开,
就需要将数据可持久化到磁盘上(更现代来说是闪存). 例如, 在 XX
管理系统中会通过语言标准库提供的文件输出接口把用户数据或日志逐行存在文件中,
在 gitlet 项目中会把 Commit 的对象等序列化后写入文件.
当然, 这些看似朴素的做法也并不是错误的, 事实上早期的数据库就是这种数据的结构和存储方式耦合度较高的做法(直到关系型数据库的提出), 而直到现在许多数据库(某些 NoSQL)也使用 JSON 等文件格式来表达一个对象的方式来存储数据. 然而, 这样的方式存在许多问题. 其中的主要矛盾是, 现实工程中的数据和数据间关系是复杂的, 而计算机科学中处理复杂问题的最主要手段(可能是唯一的手段)就是抽象. 序列化与反序列化一个对象的方式尚且较为灵活, 此处以纯文件输入输出举例: 我们可以明显看出从”纯粹文本文件”到”有语义的数据”之间有一个较大的跨度, 如果用户数据新增了某个属性(酒店管理系统新增了检验年龄的功能), 则需要重新构建整个数据文件; 除此之外, CRUD 等基本操作也过于朴素不利于优化. 这种抽象层次的缺失造成了一种耦合: 如果数据间的关系发生变化, 就会对较底层的文本文件有较大的影响, 引入无关复杂性而不利于维护(白话说就是麻烦).