“历史”数据的数据设计与实践答案

【问题标题】：data design and practice on "historical" data“历史”数据的数据设计与实践
【发布时间】：2012-10-24 20:57:47
【问题描述】：

有人可以谈谈处理在短时间内高度瞬态但必须具有多年历史存在的数据的“常见做法”或一般“可接受的做法”...

以一家小型旅游公司 - 预订旅游为例。直到旅行之前，乘客清单将是高度流动的。游览完成后 - 数据在技术上已过时，但对报告或趋势很有用...

对于高容量 - 巡演的“搜索”或“创建” - 数据库会变得很厚，数据只会很少更改。

具有相似结构的表是否很常见 - 将数据从一种状态“移动”到另一种状态（PRE/POST 事件）......就像在将数据存储到“纯”半平面结构之前的过渡报告

这是可取的、普遍的还是正确的？有没有更好的方法来做到这一点......或者圆顶 DBA 会进来并去“你在想 WTF”

【问题讨论】：

你要找的是“数据仓库”。

标签： database database-design

【解决方案1】：

标准是有某种标志来指示记录过时。有几种方法可以让您很好地处理性能问题，例如修剪和索引技术。这些可能还包括某种归档策略。您可能会将旧数据从表中移出（频率和时间取决于性能要求），或者通过某种批量插入到具有相同结构的历史表中（实际实现方式取决于您的 DBMS，但选择最健壮的方法），或者如果您的 DBMS 具有健壮的分区系统，则使用某种排序或分区策略更好。如果需要历史数据的分析师与运行操作系统的人不同，您还可以考虑某种多数据库归档策略。

【讨论】：

【解决方案2】：

当然，这样的设计决定取决于其他因素。不过，一般来说，将数据从一个表移动到另一个表并不是一个好主意。

更好的选择是在您的记录中记录生效日期和结束日期。因此，如果有人报名参加巡演，那么他们的记录就会以该日期的有效日期开始。如果他们退出，那么那个人就会得到结束日期。如果他们再次注册，他们将获得新记录，并具有新的生效日期。

这允许您重建过去任何时间点的历史记录。

【讨论】：

是的，但您最终不会得到数据库引擎必须在查询中处理的大量数据。让我们疯狂地说这是一家航空公司或类似的实体，每天有 1000 名乘客（记录）在 1000 次航班上......即使您过滤日期 - 不是吗？如果职员在 x flt 上查找 x 人——而你有 2 年的数据——其中大部分是不相关的——那么在 db 方面效率非常低
你会按索引查询相关数据，即 O(logN)。