一种用于报表服务的数据库规划的好方法

Question

设想情况：

大系统(~200表)。

60,000名用户

复杂的报告需要我为每个报表执行多个查询，甚至那些是复杂的查询，内部查询遍布各地+ PHP中的一些处理。

这一办法：

我看到了一种方法，我对此不太确定：

有一个集中式的、非规范化的表来注册系统中可报告的任何活动。这张桌子上大部分都是外键，所以她应该比较紧凑和快速。

因此，例如(我的系统是一个虚拟学习管理系统)，用户注册到课程，表存储用户id、日期、课程id、组织id、活动类型(注册)。

当然，我还将这些数据存储在规范化DB中，实际应用程序使用该数据库。

Pros:简单、可维护的查询和代码来处理数据和快速检索。

Cons:存在着非规范化表与实际DB不同步的危险。

这种方法是否值得考虑，或者(最好是根据经验)是完全$#%#%t？

Answer 1

您需要构建一个数据仓库，而不仅仅是一个非规范化的表。搜索web中有关星型架构、维度、级别、事实表的信息。或者更好地读这本书，拉尔夫·金博尔的数据仓库，有一些用过的，比如1.77美元的lol。这是最基本的数据仓库设计书籍-现实生活的建议。

Answer 2

我现在和你用的是同样的方法。

有一段时间，严格规范化的数据库会大大减慢查询速度。而且更难质疑。这是真的，没有人可以否认这个条件。

一些大公司(google，twitter，facebook)开始离开关系数据库的概念。他们开始使用自己的数据库概念(可能是)如此之多的冗余组件。但另一方面，它们的概念又带来了简单、快速的查询。

我认为您的方法很好，同时始终可以确保数据库的每一项更改都会在应用程序级别进行检查。

诚挚的问候

Answer 3

规范化是一个学术概念。很有用，但是一直坚持下去是没用的。事务是避免不一致的方法。如果冗余满足了您对更简单、更高效的查询的需求，就可以使用冗余，就像您可以拥有一个而不是10+表一样。