用于存储历史数据和显示更改的SQL数据库结构

Question

早上好，

这更像是一个概念问题。

我希望设计一个数据库和界面来跟踪条目的变化（在这种情况下是人）并轻松显示这些变化。

（用户体验看起来像这样）

for user A
 Date    Category            Activity
 8/8/14  change position    position 1 -> position 2
 8/9/14  change department  department a -> department b
 ...
 ...

视觉体验似乎会受益于E-A-V设计，但是我设计数据库以便于数据挖掘和阅读，我认为E-A-V不是正确的方法。

复制数据只是为了显示它是否有意义？ 如果没有，是否有人建议如何查询历史表和显示？ （目前使用jquery和php来利用数据库...我想我可以从编码角度做一些有趣的事情来完成它）

谢谢你的帮助，

特拉维斯

Answer 1

创建一个高效的运营数据库环境，并创建一个易于数据化的矿山＆＃39;环境是两个独立的（通常是对立的）目标。

其他人可能不同意我，但在我看来，最好根据操作准备情况创建数据库（这意味着使用上面提到的E-A-V设计），然后担心以后的数据转换。这可能使以后转换数据以便于挖掘变得不方便，但它将实现一个非常重要的目标，即消除数据错误的可能性。

一旦您拥有一个可以适当收集数据的良好系统，您就可以创建仓库或数据智能环境，以便更方便地提取数据。

这可能听起来像是很多工作，但从数据完整性的角度来看，它比尝试创建一个完全用于报告的系统更安全。这至少是我个人的意见。

Answer 2

（抱歉还不能发表评论）

您必须分析需要保留的数据。 如果你只有几张表，没有关系，你可能不需要数据库。 在这种情况下，数据库解决方案可能会更慢（连接/传输/安全开销......）。

如果它是几MB的数据，我会将所有内容保存在一个表中。 您可以轻松地将整个数据集加载到内存中并执行您需要执行的操作。