为什么我们抛弃了完美的数据模型（并用胶带获得了更好的结果）
Source: Dev.to
说实话
我们都有过这种经历。你花了数周（甚至数月）精心设计一个“完美”的数据模型，绘制错综复杂的 ER 图，争论规范化规则，并梦想拥有一个无瑕、可扩展的模式。然后第一个用户登录系统，需求发生变化，你那美丽的图表瞬间成了历史遗留。
我们在创业公司里也这样做了多年，追逐那难以捉摸的“完美”模型，用于客户分析平台。我们构建了一个拥有 47 张表、全部完美规范化的单体 SQL 数据库，结果发现销售团队需要对临时的用户行为模式进行报告，而模型在不重写一半模式的情况下根本无法满足。
我们被完美主义所束缚，错过了交付期限，甚至让自己的用户感到沮丧。代价是 数月的浪费努力，以及一个感觉像建在流沙上的系统。
事实是，在数据建模中追求完美往往意味着为一个永远不会到来的未来而构建，同时忽视了当下的紧迫需求。这并不是懒惰——而是要有战略性的聪明。当你在甚至没有用户的情况下执着于“完美”结构时，你就是在黑暗中建造。
我们吃过这口苦：数据模型应该服务于业务，而不是相反。真正的魔力在于构建 恰到好处 的结构来解决眼前的问题，然后在学习中不断适应。这并不混乱——它是务实的，也是你真正交付价值的方式，而不是仅仅追求理论上的优雅。忘掉象牙塔吧，让我们现在就构建能用的东西。
为什么“完美”的数据模型在现实中总是会失败
还记得你花了六个月时间为内部工具构建一个“面向未来”的数据模型，结果六个月后产品方向转向了吗？是的，我们也经历过。我们为 可扩展用户画像 设计的“完美”模型，在我们意识到需要跟踪实时参与度指标时就变得毫无用处。
成本不仅仅是时间——还有团队的士气。我们陷入了分析瘫痪，害怕更改模式，因为担心会破坏某个“完美”的东西。
但现实是：数据模型并非刻在石头上。它们是活的，会受到用户行为、新功能以及意外业务变动的影响。“完美”模型假设需求是静态的，而技术唯一不变的就是变化本身。
例子：我们的电商客户坚持使用一个严格的、规范化的产品变体模型（尺寸、颜色、材质）。两个月后，他们想加入一个 “可持续性评级”——一个不适合任何现有表的字段。重新构建模型会导致上线延迟数周。于是我们把新数据存储在 products 主表中的一个简单 JSON blob 里。虽然有点凌乱，但它在 昨天 就上线了，而不是下个季度。
关键洞见：完美是“足够好”的敌人。专注于以最小摩擦解决今天的问题，而不是明天的假设。正如我们的一位工程师所说：
“如果我不能在 30 秒的 Slack 信息里解释清楚数据结构，那它就太复杂了。”
Source: …
胶带方法：我们如何真正把事儿做好（且不后悔）
那么，什么是“胶带”方法？它并不是指马虎的代码——而是指 战略性的灵活性。
-
问问自己：“我现在需要构建的 最小 事物是什么，以便获得反馈？”
示例：在为我们的分析仪表盘构建新功能时，我们没有设计复杂的events表，而是使用了存放在云端的简单 CSV 文件。起初有点尴尬，但它让我们在 两天 内就测试了核心用户流程，而不是两周。 -
记录假设，而不是模式。
我们不再绘制 50 页的 ERD，而是开始写简短的备注，例如：“暂时假设所有用户只有一个邮箱；如有需要再添加多个。” 这样更改就不再像是“破坏”模型，而更像是“更新计划”。 -
**采用一个简单规则：**如果某个数据字段在一个月内 更改超过两次，就该把它正式化。
示例：我们不断调整的user_segment字段在三次快速修改后，最终被迁移到专用表中。
胶带方法并不是跳过结构——而是 在需要时才引入 结构。我们现在使用 JSON schemas 来获得临时的灵活性，然后仅在数据模式稳定后才迁移到关系表。这使我们的功能交付时间缩短了 40 %，重工率降低了 70 %。
何时抛弃模型（以及何时构建模型）
最大的陷阱？总是认为胶带是答案。事实并非如此。
| 情境 | 推荐做法 |
|---|---|
| 不会改变的静态数据（例如国家代码） | 构建正式的、规范化的模型。 |
| 动态或用户驱动的数据（例如活动日志） | 使用胶带式方案，如带版本控制的 JSON Blob。 |
| 外部合作伙伴或合规要求（例如 GDPR、PCI） | 跳过胶带；需要清晰、可审计的模式。对我们而言，这意味着为 支付数据 建立正式模型，即使它看起来“过度设计”。 |
通过评估每个数据域的 稳定性、可见性 和 监管影响，我们可以决定何时投资于稳健的模式，何时保持灵活。
如果你曾被“完美”数据模型束缚，不妨尝试胶带方法：从小做起，快速迭代，只有当模式固化时才正式化。这样可以更快交付价值，让团队保持愉快，避免在流沙上搭建。
**已工程化。**关键是要知道 为什么 要构建。我们过去为“技术纯粹”而构建模型。现在我们为 业务影响 而构建。如果数据能帮助你今天做出决策（例如“哪个功能带来最多参与度？”），就值得采用最小结构。如果它只是对未来的“锦上添花”，而那个未来可能永远不会到来，那就跳过它。
我们甚至为新项目创建了 数据模型检查清单：
- 这是否解决了当前的业务问题？
- 如有需要，我们能在 < 1 小时 内更改它吗？
- 这能在本季度为我们节省时间吗？
如果对任何一项的答案是 否，那就是胶带领域。此思维转变将数据从瓶颈转变为我们最快的增长杠杆。