YAGRI: 你最终会读取这些数据
YAGRI（You are gonna read it）是作者提出的一个建议，与YAGNI（You aren't gonna need it）相反。文章强调，在设计数据库时，除了满足当前需求的数据，还应存储未来极有可能需要读取的数据，例如时间戳和上下文元数据。作者以删除功能为例，说明了存储删除者、删除方式、时间、原因等信息的重要性。文章建议在几乎所有表中都包含created_at、updated_at、deleted_at等字段，以应对未来可能出现的分析、调试需求。虽然不应过度记录，但存储这些数据能带来长远价值，是工程师的重要职责。
YAGRI: 你最终会读取这些数据
2025年4月
YAGNI，或者说，You aren't gonna need it，是一个标准的建议，旨在警告过度工程和过早构建过多功能。我认为这很棒，可以避免浪费时间，而浪费时间可能会扼杀一个项目。
然而，我有一个例外，我称之为 YAGRI，或者说，“You are gonna read it”。这意味着你不应该只存储满足当前产品规范所需的最低数据。你还应该存储你极有可能使用（读取）的数据，例如时间戳和上下文元数据。
这个问题往往发生在 UI 设计显示你只需要向用户展示一些特定的数据时，因此你只在数据库中存储这些确切的字段。你满足了设计要求并发布了它。然后，你意识到你缺少有价值的信息来帮助调试问题、进行内部分析等等。
举个例子，这通常发生在实现一个让用户删除某些东西的功能时。简单的方法是从数据库中直接删除该行，也许这就是当前 UI 设计所要求的全部。在这种情况下，无论请求的功能集如何，作为工程师，我们都应该保持良好的数据标准并存储：
- 谁删除了它
- 他们是如何删除它的（使用了什么权限）
- 什么时候删除的
- 为什么删除的（尽可能提供周围的上下文）
一般来说，这些是在几乎任何表中都有用的字段：
- created_at
- updated_at
- deleted_at (软删除)
- created_by 等
- CRUD 期间使用的权限
这种做法的回报体现在，当你的老板突然出现在会议中，然后说“等等，我们知道为什么删除那东西吗？客户很担心……” 这样的情况下。
然而，你存储的这些字段并非每个最终都会发挥作用。但也许单个表上的单个字段会在某一天拯救你，这弥补了实施其他十几个字段的成本。我们构建的大多数应用程序，归根结底都是关于存储数据以跟踪事实。作为一名工程师，管理和维护这些数据可能是你最重要的工作。
当然，你也可以走得太远。你不应该只是记录所有东西。但我从未听人抱怨过一个表有太多的时间戳。