用ID代替文本实现规范化及其与文档模型的天然冲突

为什么简历里的”地区”“行业”这类字段常用ID而不是直接存”Greater Seattle Area”这样的 文本字符串？用ID的好处很具体：多份记录之间样式和拼写统一、避免同名歧义、修改时只 需改一处存储该信息的地方就能全局生效（比如城市改名）、支持多语言本地化展示、以及 支持更精准的搜索（地区列表能编码”西雅图属于华盛顿州”这类事实，而”Greater Seattle Area”这个字符串本身看不出来）。这背后的核心原理是：用ID时，对人类有意义的信息只 存一处，所有引用的地方只存一个没有内在含义的ID；用文本时，这份有意义的信息会被 复制到每一处引用记录里。ID的关键优势在于它对人类没有意义、因此永远不需要改变——即使 它标识的信息未来发生变化，ID本身可以保持不动；但任何对人类有意义的东西未来都可能 需要修改，一旦这类信息被复制到多处，所有冗余副本都要跟着更新，这既带来额外的写入 开销，也带来”改了一部分、漏了另一部分”的不一致风险。消除这种重复正是数据库”规范化” 的核心思想。但规范化天然需要多对一关系（很多人住在同一地区、在同一行业工作），这 恰恰与文档模型不太吻合——关系数据库靠外键和连接来处理这种引用很自然，但文档数据库 对一对多之外的关系（多对一、多对多）支持通常很弱，如果数据库本身不支持连接，就必须 在应用程序代码里通过多次查询手动模拟连接，相当于把本该由数据库承担的工作转移到了 应用层。