idkfa's questions

我目前正在为处理产品的小型微服务设计数据库模式。

该服务包含一个简单的 REST API，允许用户执行产品的基本管理，另一个 API 用于执行使用这些产品的操作。每个产品的最大消耗量受到明确定义的消耗品数量的限制。当达到此限制时，该产品将无法再食用。每个产品通常包含大约 1,000 - 1,000,000 个耗材，而单个操作一次可能需要 1 - 10 个耗材。

管理操作的频率很低，但消费操作的频率很高。

目前，该模式将所有产品信息放入一个表中。该表还包含必须在每个 INSERT、UPDATE 和 DELETE 操作上审计到基于快照的历史表中的信息。目前这是通过数据库触发器完成的，它知道如何将行与其他审计信息一起添加到历史表中。每个消耗品使用还会在消耗品表中添加一个新行，其中包含一些与消耗方式相关的附加信息。

这是一个关于这些表当前如何组织的简化示例。

------------------------
| product              |
------------------------
| + id                 |
| + name               |
| + is_enabled         |
| + consumable_limit   |
| + consumable_counter |
| ...10 omitted fields |
------------------------

------------------------
| product_history      |
------------------------
| + id                 |
| + product_id         |
| + time               |
| + user_id            |
| + history_type       |
| + name               |
| + is_enabled         |
| + consumable_limit   |
| + consumable_counter |
| ...10 omitted fields |
------------------------

------------------------
| operations           |
------------------------
| + id                 |
| + product_id         |
| + consumable_idx     |
| ...10 omitted fields |
------------------------

在上图中，我省略了一些字段以使事情更简单。让我想知道的是，产品表中的 consumable_counter 会随着消费操作快速更新，这可能会进一步淹没 product_history 表。每次更新 consumable_counter 时，将 consumable 计数器移动到另一个表中不会触发产品表行的完整快照会更好吗？不知何故，我觉得它可能是理想的，因为 consumable_counter 是产品表中唯一以高速率更新的列。每个计数器增量的完整快照不知何故感觉有点矫枉过正。

编辑

consumable_counter充当相应产品已使用次数的计数器。当达到consumable_limit时，产品将无法再被消耗。

编辑

每次消费产品时，都会在操作表中添加一个新条目。此表中的条目还充当包含将在操作执行流程期间管理的状态的业务逻辑事务。

我目前正在为处理产品的小型微服务设计数据库模式。

该服务包含一个简单的 REST API，它允许用户执行产品的基本管理以及一些端点来查询有关产品的完整审计历史记录。Schema 已经包含一个基于快照的产品审计表，以支持存储每个产品的完整审计跟踪。

除了具有单独的审计历史端点之外，每个产品特定的 REST API 响应还必须包括 createdAt、createdBy、updatedAt、updatedBy 字段。我在这里想知道的是我应该将这些字段添加到产品表中还是直接从产品审计表中查询这些字段的信息更好？不知何故，当可以从审计表中查询相同的数据（甚至更多）时，我觉得将这些字段添加到产品表中似乎有点矫枉过正。

编辑

对产品表的每个 CREATE、UPDATE 和 DELETE 操作也会将一个新条目附加到审计表中。此审计表包含与实际产品表相同的列，以及用于审计事件的时间戳、用户 ID 和类型（ADD、MOD、DEL）的附加列。管理操作的频率非常低。