Schema-less设计的隐藏技术债：数据可以随意塞进去，问题是出了事都找不到源头

Schema-less（无固定结构）的设计有明确的优势：业务模型可以更灵活，不需要像传统关系表那样提前定义好每个字段才能存数据；但这份灵活性也有明确的劣势——额外的空间占用（因为每条记录可能要重复携带字段名信息），以及一个更隐蔽、更难被提前意识到的代价：技术债。作者分享了一个真实的亲身经历：曾经维护过一个所有数据都用Map存储的系统，结果到后来发现系统里出现了一些诡异的数据，却完全不知道这些数据是什么时候、被系统的哪个环节塞进去的——因为Map这种结构本身没有任何约束，任何代码路径都可以往里面随意塞入任意的键值对，一旦真的出现了异常数据，想要调试、想要追溯这条数据到底是从哪里来的，会变得异常困难，因为系统本身没有任何机制去限定”哪些字段应该存在、由谁负责写入”。这个案例给出的经验是：Schema-less这类设计的灵活性，本质上是把原本应该在设计阶段就明确下来的约束（这条数据应该有哪些字段、由谁负责写入、写入时机是什么），推迟到了运行时才由具体调用方各自决定——这种推迟不是免费的，它把原本可以在开发阶段就通过Schema约束提前暴露出来的问题，转移成了运行时才会暴露、而且极难排查定位的问题，本质上是一种典型的技术债：短期内换来了更快的开发速度和更灵活的业务适应能力，长期看却在系统的可维护性和可调试性上欠下了债务，这笔债务迟早需要偿还，而且往往是在最不方便的时刻（生产环境出现诡异数据）才被迫兑现。这也是为什么作者认为”结合起来会更好一些”——比如PG和MySQL近年开始支持JSON字段，本质上是在保留关系模型主体结构约束的同时，给需要灵活性的那一小部分数据开一个受控的口子，而不是让整个系统彻底退化成一个无约束的Map。