为何Common Data Model与Dataverse的Account表内置两套地址字段而非拆分独立关联表？

这个设计并非违反常规关系数据库设计原则，而是面向低代码业务平台的场景化取舍，核心考量有以下几点：

• 低代码体验优先的核心目标
  Dataverse的定位是支撑无代码/低代码用户快速搭建业务应用，如果采用独立地址关联表，制作账户详情表单、列表视图时，普通业务用户需要掌握多表关联、连接查询的配置逻辑，门槛极高。内置地址字段可以直接拖入界面、直接在视图中展示，不需要额外配置关联逻辑，同时能大幅降低列表查询的性能开销，避免每次加载账户列表都关联查询地址表造成的延迟。
• 覆盖绝大多数开箱即用的高频场景
  面向中小企业销售、服务类的通用场景中，绝大多数Account（客户、经销商、合作伙伴类主体）仅需要两个常用地址：一个用于日常对接的主要联系地址，一个用于账单寄送的备用地址。内置这两组字段已经可以覆盖80%以上的默认业务需求，不需要用户额外建表、配置关联逻辑，大幅降低初期系统部署的工作量。
• 历史兼容性的强约束
  这套Account表结构从早期的Dynamics CRM时代就已经定型，经过近20年的用户迭代，大量存量业务系统已经基于这套内置地址字段做了流程、报表、界面的定制，甚至形成了微软生态的事实标准。如果贸然改成关联地址表，会导致数十万存量部署的客户出现系统升级断裂，兼容性成本远大于设计优化的收益。
• 保留扩展空间的兜底设计
  内置地址字段并非限制多地址场景的使用，如果实际业务存在单账户对应3个及以上常用地址的需求（比如连锁客户的多门店地址、多收货地址），完全可以在Dataverse中自行创建独立的Address表，与Account建立一对多关联，和原有内置的两套地址字段共存使用，不存在设计上的冲突。

内容的提问来源于stack exchange，提问作者Maciej Pokrzywiński