让您的数据保持原始状态

我想谈谈多年来一直对我有用的简单经验法则：“如果您的数据依赖于其他数据，请尽量不要存储它。”如果你遵循这个规则，你可以更快地交付你的代码，主要是因为你避免了漫长而痛苦的数据迁移。回到上面的引述，“静止的数据比运动的数据更危险。” “静态数据”通常是指存储在磁盘上的数据，但它也可以是通过代码更新保留在系统中的任何数据。例如，在 Web 应用程序的上下文中，PostgreSQL 数据库中的行将是“静止的”。或者，当数据从数据库中获取、转换和提供时，我们可以说它在应用程序的内存中“处于运动中”。它不容易版本化。您主动运行的 Web 应用程序的数据库可能存储了一些快照，但它不像您的代码那样递增版本化。更新代码应该比手动弄乱数据库更危险。它的格式不容易改变。当您决定更改数据库列的字段时，或者当您决定在 ElasticSearch 中使用 float 而不是 int 时，进行这些更改可能会非常痛苦。您可能需要编写自定义脚本或执行昂贵的重新索引工作。相反，更改处理内存中数据的代码通常既简单又安全。希望它甚至有单元和集成测试。数据具有依赖性。您的代码依赖于数据，而不是相反。因此，当您更新数据格式时，您需要将该更改与依赖它的代码同步。您可能还需要一个数据回滚计划，以防出现问题。通常，当您的应用程序运行时，存储在内存中的数据是短暂的——您不会依赖于它在那里的任何时间长度。设备和服务器重启将清除所有内存数据，这没关系。

由于您的代码主动处理的数据是短暂的，因此我们可以不受惩罚地进行代码更改。只要新版本的代码与其自身（以及它所依赖的危险持久数据）一致，那么更改就很容易了。规则：“当您拥有依赖于其他数据的数据时，请尽量不要存储它” 例如，假设您正在构建一个电影评论应用程序。在您的数据库中，对于每个评论，您存储一个名为 num_stars 的字段，它只是一个介于 1 和 5 之间的整数。然后，在开发后期，产品团队要求一个新功能，该功能根据评论的数量在评论上显示颜色星星。 1 星和 2 星将显示为红色，3 星将显示为黄色，而 4 和 5 星将显示为绿色。有几种方法可以构建此功能。您可以在数据库中创建一个名为 color 的新字段。每当创建评论时，您只需检查星星的数量，并基于此生成颜色字段并存储它。现在，当用户从数据库中提取该评论时，它已准备好使用生成的颜色字段！每当从数据库请求评论时，应用程序代码都会提取评论数据，然后通过进行事后计算生成颜色。这两个选项可能同样容易编码和发布。选项 1 的问题只会在稍后出现。让我们来看看一些潜在的问题。我们决定需要五种颜色。 2 星的评论现在是橙色的，而 4 星的评论是黄绿色的。因为存储了颜色数据，所以我们需要编写一个脚本来根据依赖（num_stars）更新数据库中的所有颜色。如果我们采用选项 2，它将像更新和部署一些代码一样简单。

部署了一个错误。一个新的开发人员误解了在数据库中生成和插入颜色字段的代码的用途。因此，他们部署了一个小错误，无论 num_stars 字段如何，都将颜色设置为始终为绿色。再次发现错误后，我们将需要编写一个潜在危险的脚本或查询来修复错误的历史数据。我们是否使用了选项 2，这将是一个简单的代码修复。存储直接依赖于其他数据的内容是否是个好主意？例如，有时出于性能原因需要这样做。假设您有一些原始播客音频数据，并且您希望能够向用户显示转录内容。每次用户想要查看转录内容时，重新转录音频都太慢且成本太高。在这种情况下，我们只需要硬着头皮存储计算出的文本数据。如果您有任何问题或意见，请在 Twitter @q_vault 上关注我。如果我在文章中犯了错误，请告诉我，以便我改正！