【问题标题】:A good approach to db planing for reporting service用于报告服务的数据库规划的好方法
【发布时间】:2011-03-05 06:07:00
【问题描述】:

场景:

大系统(约 200 个表)。
60,000 名用户。
复杂的报告将需要我为每个报告执行多个查询,甚至那些将是复杂的查询,内部查询遍布整个地方 + 一些 PHP 处理。

方法:

我见过一种方法,但我不确定:
拥有一个集中的、非规范化的表格,用于记录系统中任何可报告的活动。这张表将主要保存外键,所以她应该相当紧凑和快速。
所以,例如(我的系统是一个虚拟学习管理系统), 用户注册课程,该表存储用户 ID、日期、课程 ID、组织 ID、活动类型(注册)。
当然,我还将这些数据存储在一个规范化的 DB 中,供实际应用程序使用。

优点:简单、可维护的查询和代码可用于处理数据和快速检索。
缺点:存在非规范化表失效的危险与真实数据库同步。

这种方法是否值得考虑,或者(最好根据经验)总计 $#%#%t?

【问题讨论】:

    标签: php mysql reporting-services denormalization


    【解决方案1】:

    您需要构建一个数据仓库,而不仅仅是一个非规范化表。在网络上搜索有关星型模式、维度、级别、事实表的信息。或者更好地阅读这本书Ralph Kimball's Data Warehousing Toolikit 有一些二手的,价格为 1.77 美元,哈哈。这是基本的数据仓库设计书籍 - 现实生活中的建议。

    【讨论】:

      【解决方案2】:

      我现在对您使用相同的方法。

      有时严格规范化的数据库会大大降低查询速度。而且也更难查询。确实如此,没有人可以否认这个条件。

      一些大公司(google、twitter、facebook)开始离开关系数据库的概念。他们开始使用自己的数据库概念,其中包含(可能)如此多的冗余组件。但另一方面,他们的概念带来了简单且非常快速的查询。

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

      最好的问候

      【讨论】:

        【解决方案3】:

        规范化是一个学术概念。非常有用,但一直坚持下去也没用。事务是避免不一致的方法。如果冗余可以满足您对更简单、更高效的查询的需求,例如您可以拥有一个而不是 10 多个表,请利用冗余。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 2011-11-12
          • 1970-01-01
          • 2019-11-13
          • 1970-01-01
          • 2010-09-05
          相关资源
          最近更新 更多