新至SFMC之队，随需而创数据拓展。今次发送需列，明日忠诚功能需别DE，下周CRM同步又增三。三月之后：二十DE，无可联，无跨数据分群，无审计踪迹.
其解，乃创首DE前，白板三十分钟之思。二理担此：记录数据库与基数.
记录数据库（DBOR）
DBOR者，订阅者之身份唯一真源也。凡他数据之源，皆指向此。
问于客：
一答而已。若客言“皆选之”，则助其决断——通常择当前驱动业务之系统（如订单履行、客户服务诸事）。
DBOR者，定义订阅者之钥也。凡SFMC之数据元素持订阅者信息者，皆用一标识符，溯源于DBOR.
订阅者钥之策
既定DBOR，则订阅者钥随之：
- 若DBOR为Salesforce CRM，则用CRM ContactID为订阅者钥.
- 若DBOR为电子商务，则用电子商务客户ID。
- 若DBOR为数据仓库，则用此仓库所赋之恒定ID（常为UUID）。
订阅者密钥必恒定，不可更易于客户之终身。电子邮件易变；Shopify ID可于店铺迁移时重置；特制之CustomerID最为稳妥。
于数据模型文书记载订阅者密钥之规。后至之新数据源，亦循此密钥接通。
吾等所常用之辐辏式也
非独设一巨DE，而以功能分列：
主表存面向订阅者之属性。辐表存详实。联结由AMPscript Lookup或Automation Studio SQL为之，非复制列也
接触构建者中基数之理
尔以联接DE于接触构建器为跨DE分群，SFMC询及基数——即两DE间之关系：
基数义例>一与一A之一行关联于B之一行主地址（每客有一主）__JHSNS_SEG_383db94e_20__>一与多A之一行关联于B之众行客主__JHSNS_SEG_383db94e_22__> 订单（一客多单）多：多在 A 中多行关联 B 中多客户 -> 产品（经订单项 - 每客可购多品，每品被多客购）
取基数误，破分割：
- 声称 1:1 而实为 1:多，则 SFMC 忽略除首匹配行外所有行。
- 声明一：虽为1:1，然误选多行亦无害，然易致误选。
- 多对多关系，需设中表（Order_Items）以解之。
所撰数据模型之文
新事始，未触SFMC，先撰一页数据模型：
- DBOR - 哪系统为真源。
- 订阅者密钥——确指字段名、数据类型、其源所自.
- 主数据实体——列明字段、类型、可空性、源系统.
- 支点数据实体——名称、用途、与主数据实体之关联度、源系统.
- 查找数据实体——名称、用途、主键.
- 联系构建者关联——何等数据实体得相联、关联度。
与客评之。既签可，则SFMC之建，依文书而行，非文书依建而行也。
何以此事关乎承继之约
及取劣构之SFMC账户，其状可预。
- 当分割本应可能时，却不可为。
- 一人屡现于众。
- 跨系统报告须于SFMC外以SQL构建之。
- 联系构建器有十五系相联，而无人知其基数。
纠偏之道，无论初创或改造，皆同：明定DBOR，修整订阅键，引入主系，迁下游之数。
所得之理
数据建模之工，未有所成，故感无益。于SFMC之业，此乃全项目中最得力之时。撰数据模型之文，得客户之允，而后营建。否则，将陷于20-DE之蔓延，耗尽尔Q2之期。
欲模SFMC之数据架构乎？吾Salesforce之众，于生产之役，设计数据模型、订阅者键之策、联系人构建之系也。接洽于我——>
览吾之平台全务，知所覆之栈。