《架构整洁之道》第 30 章 数据库只是实现细节
0 / 0 / 创建于 1年前
巴啦啦 的个人博客
均为原创，读架构整洁之道的笔记。
包含了部分自己的理解，包含了原书中至少70%的知识点。
完整笔记，各位老哥友链加起来吧。
我的博客地址：www.yuque.com/_huangkuan
从系统架构的角度来看，数据库并不重要，它只是一个细节，数据库与系统架构的关系，就像房屋结构和门把手的关系。
这里我们说的是数据库，并不是数据模型。数据库只是一款软件。从系统架构的角度上来讲，它只是工具，是一个达成目标的手段。一个优秀的架构师是不会让实现细节污染整个系统架构的。
关系型数据库
关系型数据库是目前的主流数据库，但不管它如何优秀精妙，对于系统架构来说，它终究只是细节。关系型数据库的表模型设计，对某一些数据访问会比较方便，但是把数据按行组织成表的结构，对于系统架构来说并没有什么重要意义。
应用程序的用例不应该知道，也不应该关心这些细节，需要了解表结构的代码应该被限制在系统架构的最外围。
很多数据访问框架，允许将数据行和数据表以对象的形式在系统内部传递。这么做从系统架构上来说是错误地，因为这会导致架构中的每一层都与数据模型绑定在一起，形成了依赖。
为什么数据库系统如此流行
数据库流行的原因是因为硬盘。随着硬盘技术发展，硬盘的体积越来越小，容量越来越大，访问速度越来越快。但是即使已经很快了，对于处理器来说还是太慢了。所以为了应对硬盘的访问速度慢，就出现了索引，缓存，查询优化器等技术。
现已经有了两种截然不同的数据库系统：文件系统，关系型数据库系统。
文件系统基于文档格式，查找文件名很方便，如果要搜索文件内容就很难。
关系型数据库系统关注的是内容，擅长查找某些共同属性的搜索。
这两种系统都是为了优化磁盘存储而设计的，我们需要根据特点来将数据组织成便于访问的模式。
假设磁盘不存在会怎样
虽然磁盘很常见，但其实它在走下坡路了，很快就会和CD，磁带，软盘一样成为历史。RAM正在代替一切。
现在我们考虑一下，如果所有数据都存在内存中，应该如何组织它们？需要按表格存储并按SQL查询吗？需要按文档存储，然后按目录查询吗？
当然不会，我们会将数据存储为链表，树，哈希，等数据结构。然后用指针访或者引用来访问它们。
事实上，我们已经开始这样做了，就是缓存层。
实现层
上面所说的，就是作者认为数据库只是一个细节的原因。数据库终究只是硬盘和内存之间互相传输数据的一种手段，它只是一个可以长期存储数据的一个介质。
因此，从系统架构的角度来看，不应当关心数据库的具体细节，对磁盘本身也不应该关心。
但性能怎么办呢
性能难道不是系统架构的一个考量吗？当然是的，但是问题涉及到存储时，这些操作通常是被封装起来的，业务逻辑应当不可见。也就是说，我们确实需要快，但这终究只是底层的实现问题，和我们的业务无关。我们完全可以在底层解决访问数据的问题，而不应当和业务逻辑挂钩。
一段轶事
作者很久以前，做了一个项目，因为使用的是内存，就没有选择使用关系型数据库。但是后来来了一个市场部经理，说这需要一个关系型数据库，并说这不是一个技术问题，而是市场问题。后来公司有一位硬件工程师，也被关系型数据库所感染，他背着作者召集管理层开会，说明关系型数据库很重要。于是作者一直和这两个人做斗争。
最后作者输了，这位硬件工程师被提拔为软件开发经理。最终作者承认了他们是对的。
但这并不代表在软件工程上作者错了，作者错的原因在于，他们公司的客户合同上，明确的要求了需要使用关系型数据库。尽管这背后毫无工程逻辑，是不理智的外行的。但却又是真实存在的。
这种需求，来自于数据库厂商有效的数据库推广，他们说服了企业高管，他们的数据资产需要某种保护，而刚好数据库能够提供。
直到今天，我们依然能看到这类宣传，譬如企业级，面向服务的架构，这大多都是噱头，而跟实际的工程质量无关。
回头想想，我在这个场景中应该怎么做呢？事实上，我应该在系统的某个角落接上一个关系型数据库，在维持系统核心数据的同时，给关系型数据库提供一些安全的，受限的数据访问方式。但作者没这样做，辞职了，干起了咨询这一行。
本章小结
数据的组织结构，数据的模型，都是系统架构重要的部分，但是从磁盘上存储/读取数据的机制和手段，相对于系统架构来说，就没那么重要。关系型数据库强制我们将数据组织成表格，并且以SQL的形式访问，主要是为了存储/读取数据的机制和手段。
总而言之，数据本身很重要，但数据库仅仅是一个细节。
本作品采用《CC 协议》，转载必须注明作者和本文链接
关于 LearnKu
粤公网安备 44030502004330号