【发布时间】:2014-03-07 17:51:13
【问题描述】:
情况
我正在为一个跟踪超过 200,000 个序列化设备的应用程序创建库存历史记录。目标是能够及时回顾并准确知道设备在 X 天的位置。
我认识到理想的情况可能是在项目立即更改时触发触发器以更新历史记录,但这将是一项非常大规模的任务,并且无法通过当前应用程序轻松实现。
考虑到这一点,我们决定每晚运行一个脚本,检查当前库存并将其存储到跟踪库存位置、状态等的inventory_history 表中。最初,我们试着每天都在历史中扑通扑通。 IE 每天插入 200,000 行,每 5 天产生超过 100 万条记录。我们发现这将在不到一年的时间内产生 GB 的数据。我提出的解决方案是在版本控制风格的历史中实现它。因此,与其每天插入 200,000 条记录,不如只插入已更改的记录。 (并为已删除的记录插入已删除的记录。)
问题
- 这种方法有什么明显的问题吗?对于不是为历史设计的已构建应用程序,是否有更好的替代方法?
- 如果这种方法很好,需要实施哪些我可能会遗漏的方法?目前我实现了以下场景:
- 插入,如果不存在完全相同的值。
- 如果当天未找到设备,则插入删除记录。
- 选择时,使用历史搜索允许的最近日期按设备 ID 分组。 (如果我们想知道 2014 年 1 月 1 日的库存状态,不要选择之后发生的任何记录,而是将记录分组,以便显示的是最新的。)
备注
当我们查看历史记录时,有时我们想知道特定的设备,而有时我们想要当天的库存摘要报告。
【问题讨论】:
-
您如何知道记录何时更改?库存表中是否有字段(例如 last_updated)?
-
比较当前实际库存与当前历史库存。它比较我们专门跟踪的值。 (位置、状态等)
标签: mysql inventory-management historical-db