根据更新频率将可审计表拆分为两个表是个好主意吗？
我目前正在为一个处理产品的小型微服务设计一个数据库模式。
该服务包含一个简单的REST (允许用户执行产品的基本管理)和另一个API (用于执行使用这些产品的操作)。使用显式定义的消耗品计数，每个产品的最大消耗量是有限的。当达到这个限制时，产品就不能再消费了。每个产品通常包含约1,000 - 1,000,000件消耗品，而一次操作一次可消耗1- 10件消耗品。
管理操作的频率较低，但消耗率很高。
目前，模式将所有产品信息放入一个表中。此表还包含必须审计到每个插入、更新和删除操作的基于快照的历史记录表中的信息。目前，这是使用DB触发器完成的，这些触发器知道如何向历史表中添加行以及其他审计信息。每一种消耗品使用都会在消耗品表中添加一个新行，并提供与其使用方式有关的其他信息。
下面是一个关于这些表当前组织方式的简化示例。
------------------------
| 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_counter是产品表中唯一正在以高速率更新的列。每个计数器增量的完整快照不知怎么感觉有点过火了。
编辑
consumable_counter充当相应产品被使用多少次的计数器。当它到达consumable_limit时，产品就不能再消费了。
编辑
每次使用产品时，都会在操作表中添加一个新条目。此表中的条目还充当业务逻辑事务，其中包含将在操作执行流程期间管理的状态。
回答 1
Database Administration用户
发布于 2020-10-04 12:34:08
我认为你的评估方向是正确的。你确实捕获了太多的信息。根据你的描述，我认为你描述的是一个消费事件，而不是产品历史。
我的建议是将消费属性从PRODUCT_HISTORY表中分割成一个新表。如果不知道省略的列，我就无法提供建议。以下是一些想法：
- 如果" name“列是产品的名称，则这不会随消费事件而改变，应该保留在产品历史记录中。
- consumption_limit可能需要在产品历史记录和消费事件表中。您可能需要知道消费发生时的限制是什么，限制可能会随着时间的推移而改变，因此应该将这一事实记录在产品历史表中。
- 可能需要在消费事件和操作表之间建立关系。
操作表中的一行描述单个操作的集合(可能有一个操作表)，还是单个操作？这是一个重要的细节，以确定与消费事件的关系。如果是单数，我建议您重命名该表。
https://dba.stackexchange.com/questions/276410
复制相似问题
腾讯云开发者
