一段轶事：市场需求驱动关系型数据库引入的真实故事

作者亲历的故事，印证了[[数据库只是实现细节区分重要的数据模型与不重要的数据库工具]]在现实里遭遇的真正阻力往往不是技术层面的。80年代末，作者带队开发一套监控T1线路通信质量的网络管理系统，数据之间几乎没有内容关联，用简单的可随机访问格式、树和链表存储，为便于加载进内存处理而设计，完全不需要关系型数据库。公司招来的市场推广经理却坚持系统必须有关系型数据库——”这容不得商量，不是工程问题，是市场问题”。作者当时想不通：为什么要把已经用得好好的链表和树重组成表和行、用SQL存取？后来一位被”关系型数据库大潮”感染的硬件工程师背着作者召集管理层开会，在白板上画了一间用几根杆子支撑的房子问”谁会把房子建在几根杆子搭起来的地基上”——言下之意是用关系型数据库存文件比自己存更可靠。作者据理力争、坚持到底，但这位硬件工程师最终被提拔为软件开发经理，系统还是加入了关系型数据库——作者最终承认”他们是对的，我是错的”，但这个”错”不是工程层面的：作者仍然坚持系统核心架构不该引入关系型数据库，错的地方在于低估了客户的诉求——客户希望系统里有关系型数据库，即便他们自己根本没机会直接用它，这已经成为当时所有软件采购合同里的必选项，毫无工程逻辑，纯属数据库厂商多年市场推广的成果（说服企业高管相信”数据资产”需要某种保护，数据库恰好提供了看似便捷的保护感）——就像今天”企业级”“面向服务的架构”这类措辞大多也是市场噱头，与实际工程质量无关。作者事后反思，当年该做的是在系统某个角落接上关系型数据库、给它提供受限的安全数据访问通道，同时维持系统核心数据结构不变——但他没这么做，选择了辞职去做咨询。