这些信息应该实时计算还是存储在单独的数据库中?

时间:2014-06-24 00:22:16

标签: database database-design database-schema

我正在开展一个小组项目,我们正在讨论是否要从现有数据库计算我们想要的数据并将其存储在新数据库中以便稍后查询,或者每次我们计算现有数据库中的数据需要使用它。我想知道这两种实现的优缺点是什么。你有什么建议吗?

编辑:这里有更详细的解释。我们有一个大型数据库,每天都有大量的信息提交给它。我们正在构建一个跟踪某些数据点的系统。例如,我们获取用户执行数据库中输入的内容的次数。使用这个例子(实际的想法有点复杂),我们正在讨论获取每个用户的操作计数的方法。第一种方法是创建一个存储用户及其操作计数的数据库,并在每次需要操作计数时查询该数据库。第二种方法是查询大型数据库,并在每次需要使用它时计算每个用户的操作。我希望这个解释有助于解释。想法?

编辑2:另外两个可能有用的东西是1:我只对大型数据库有读取权限; 2:我的最终目标是在最终用户的网页上显示这些信息。

1 个答案:

答案 0 :(得分:1)

这是关于通过缓存进行优化的一般性问题。以下是我对基本相同问题的回答。尽管这个问题提供了大量不同的细节,但它们都不具备足够的特性,不值得一般的答案:

  

您想要在查询时计算得越多,您想要的视图越多,   计算列和存储或用户例程。你想要的越多   在标准化的基础更新时间计算,您想要级联的越多   和触发器。你想要计算的其他一些(计划的)   或临时)时间越多,您使用快照即物化视图和   更新的非规范化基础。你可以结合这些。任何时候   数据库被访问它可以由存储启用和限制   例程或其他api。

     

直到你可以证明他们是充足的,观点和计算   列是最简单的。

     

DBMS的整个想法是存储您的表示   应用程序状态作为数据库(规范化减少了   冗余)然后你查询并让DBMS实现和   优化答案的计算。你没有提出理由   不要以最直接的方式做到这一点。

[sic]

始终确保应用程序正在阅读自己的个人("外部")数据库,该数据库是""" ("概念性")数据库,以便当您更改前者的实现(加上其余的某些组合的interfact)后者(加上其他一些组合机制)时,您的应用程序不必更改( "逻辑独立")。这里的应用程序是您的用户'和你的跟踪器'。

最终你必须得到仪器和猜测。当它值得你开始缓存。优选地,在视图和快照等高级概念方面尽可能多,并且在非DBMS代码中尽可能少。关系模型的一个好处是,就另一个简单的关系接口而言,很容易描述一个直截了当的关系接口。您可以通过提供hides secrets实现的接口或当前接口系列中的哪一个来保护您的应用程序免受更改。