其他
小李的数据库之旅（上）
所以一入学，辅导员就找到小李让他帮忙给系里开发个信息系统， 记录系里的学生信息，课程信息， 还有选课， 这样的话就可以无纸化办公了 。
小李觉得这只是一个基于命令行的程序， 无非是增删改查嘛，就满口应承下来， 然后祭出Pascal 大法，准备大干一场。
辅导员把相关的资料也送来了， 这学生信息无非是[学号，姓名，性别，身份证号，入学日期，班级] 等信息。 课程信息也就是[课程号，课程名，授课老师] , 选课是[学号，课程号，成绩]
有了基本的数据结构， 小李决定用三个独立的文本文件来存储这些信息， 比如说student.txt 中的内容是这样：
编程工作进展的非常顺利， 最重要的部分无非就是用Pascal读写文件而已， 一周不到就完工了， 现在程序架构是这个样子的：
可是有些计科系的学生到商学院去选修经济学的课程时， 发现还得再输入一遍学生信息， 这实在是太烦人了。
小李也没办法， 毕竟这是两套系统啊， 只有采用土办法， 把计科系的student.txt 复制了一份到商学院。
这样一来数据的重复难于避免了， 更有可能出现数据不一致的地方， 比如地址信息在计科系改了， 但是商学院没改。
后来辅导员说数学系自己也搞了一个类似的系统， 不是用Pascal而是用C写的， 数据格式和小李定义的还不一样， 小李想把Student.txt复制过去也不可能了。
小李想要是学校所有的院系都用这么一套系统就好了。 其实学校领导也看到了这个问题， 只是现在的校内局域网还没有建立起来， 大家用同一套系统并不现实。
“小李，我想算一下经济学的平均分， 能不能程序实现一下？ 学生太多，手工算太麻烦了 ”......
为了应付这些“变态”的需求， 小李假期几乎没怎么休息， 不停的用PASCAL写各种各样的功能。
可是这种需求似乎无穷无尽， 总结一下，无非就是对这些文件的各种各样的查询而已。
难道让老师们直接去文件中查找和计算吗？ 显然不行。
小李想起了一句话： “ 所有计算机的问题都可以通过增加一个中间层来解决”
那提供一个中间层吧， 把文件层屏蔽掉， 让老师们在这个中间层用自己熟悉的术语进行查询。
中间层上要有逻辑的数据结构，其实就是这些东西：学生信息：[学号，姓名，性别，入学日期，班级，地址]
课程信息：[课程号，课程名，授课老师]
选课 ：[学号，课程号，成绩]
小李决定把这些东西称为“表” ，其中的每一项称为“列”/“字段”/“属性”， 每一列都有类型，例如字符型，日期型，数字型等等
查询的话是用类似这样进行的： SELECT 学号，姓名 FROM 学生信息 WHERE 入学日期='1991-9-1'
想把几个表连接起来查询也可以：
SELECT 学号，姓名, 课程名，成绩FROM 学生信息 s , 课程信息 c， 选课 scON s.学号=sc.学号 AND c.课程号=sc.课程号 WHERE 课程名='操作系统' AND 成绩<60
很明显小李需要写一个解析器， 把这样的语句变成内部对文件的操作， 还好小李已经有一点编译原理的基础了， 努力一下还是能写出来的。
小李把查询规则给各个老师做了个简单的培训， 从此以后， 只要不是超级复杂的查询， 老师们自己就搞定了，再也不用骚扰小李了。
无心插柳柳成荫，小李忽然发现，自己的程序也可以调用这样的抽象层来编程啊， 也不用直接操作文件了， 简化了好多。
（码农翻身注：其实就是SQL了）
可是小李一直是隐隐觉得不安， 不知道这种查询方式有没有漏洞， 后来看到埃德加·弗兰克·科德 的论文 “A Relational Model of Data for Large Shared Data banks（大型共享数据库的关系模型）”，这才明白，其实这就是所谓的关系模型啊， 其背后的有着坚实的数学基础， 肯定是没有问题的。
有了一个中间的逻辑层， 还带来了一个额外的好处，现在小李可以对物理层的文件存储做一些优化了， 为了加快访问速度， 小李不再采用简单的逗号分隔的文件， 还增加了索引、B+树，缓存等手段。由于有中间层的存在，这些变化对应用层没有什么影响。
（未完待续）
你看到的只是冰山一角， 更多精彩文章，尽在“码农翻身” 微信公众号， 回复消息"m"或"目录" 查看更多文章
有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan QQ: 3340792577
掘金是一个高质量的技术社区，从 Swift 到 React Native，性能优化到开源类库，让你不错过互联网开发的每一个技术干货。长按图片二维码识别或者各大应用市场搜索「掘金」，技术干货尽在掌握中。