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

早上好

这更像是一个概念问题，而不是任何问题

我期待着设计一个数据库和界面，将跟踪更改的条目（在本例中的人），并显示这些变化容易

（用户体验应该是这样的）

视觉体验似乎会从E-A-V设计中受益，但是我设计的数据库很容易进行数据挖掘，从我的阅读来看，我认为E-A-V不是正确的方式

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

谢谢你的帮助

---

Travis

创建一个高效的操作数据库环境和一个“易于数据挖掘”的环境是两个独立的目标（通常是相反的）

其他人可能不同意我的观点，但我认为最好根据作战准备情况创建数据库（这意味着使用上面提到的E-A-V设计），然后再考虑数据转换。这可能会给以后转换数据以便于挖掘带来不便，但它将实现一个极其重要的目标，即消除数据错误的可能性

一旦您有了一个可以适当收集数据的好系统，那么您就可以创建一个仓库或数据集市环境来更方便地提取数据

这听起来可能需要做很多工作，但从数据完整性的角度来看，这比尝试创建完全用于报告的系统要安全得多。这至少是我个人的看法。

（抱歉，现在还不能评论）

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

如果是几兆字节的数据，我会把所有数据都放在一个表中。

---

您可以轻松地将整个数据集加载到内存中，并执行需要执行的操作

谢谢你的观点。我想在提交到EAV结构之前，我需要确保UI比数据挖掘更重要。谢谢用户。这只是数据库将提供的整个“工具”的一小部分。最终，它将跟踪“很多”人员的不同方面（培训、认证等）。用于历史记录显示的表格上的单行项目很容易查询，最大的问题是提供对人员在公司中移动方式的即时了解。因此，如果有大量数据，用CategoryID替换类别并创建可能包含一些子类别的类别表是有意义的。仅供参考：通常的做法是只记录以前的状态，因此不需要指定部门A->部门b。（部门B为当前部门）

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