1

我正在创建一个用于技术分析的数据库模式，比如销量最高的赢家、价格最高的赢家等。我在这里检查了问题 的答案，比如设计问题。从boe100的答案中得到提示后，我有一个几乎以它为模型的模式，因此： 

Symbol -  char 6               //primary
Date -  date                   //primary 
Open -  decimal 18, 4
High -  decimal 18, 4
Low -  decimal 18, 4
Close -  decimal 18, 4
Volume -  int

现在这个包含 End Of Day (EOD) 数据的表在 3 年内将有大约 300 万行。后来当我获得/需要更多数据时，它可能是 2000 万行。

前端将询问诸如“在 X 天超过 Y 天给我价格涨幅最高的人”之类的请求。我认为该请求是较简单的请求之一，因此在时间上不会太昂贵。

但是像“给我过去 10 天的最大销量增长者，以前 100 天为基准”之类的请求可能会花费 10 到 100 倍的成本。这样的请求的结果将是一个浮点数，表示体积增长了多少倍等。

我有一个选择是为每个这样的结果添加一列。如果用户在 20 天内要求在 10 天内增加交易量，则需要另一列。此类列的总数很容易超过 100，特别是如果我开始将其他结果添加为列，例如 MACD-10、MACD-100。每个都需要自己的列。

这是一个可行的解决方案吗？

另一种选择是我将结果保存在缓存的 html 文件中并将它们呈现给用户。我在网络开发方面没有太多经验，所以对我来说看起来很乱；但我可能是错的（ofc！）。这也是一种选择吗？

让我补充一点，我正在/将使用 mod_perl 向用户呈现响应。mysql 数据库的大部分工作都是使用 perl 完成的。我希望有 1-2 秒的响应时间。

4

1 回答 1

2

您应该尽可能地保持数据标准化，并让 RDBMS 完成其工作：根据标准化数据高效地执行查询。

不要事后猜测什么会或不会有效；相反，仅针对RDBMS 的查询解释器报告的特定的、可衡量的低效率进行优化。

有效的优化工具包括，按粗略的优先顺序排列：

  • 进一步规范化数据，以允许 RDBMS 自行决定如何最好地回答查询。

  • 重构特定查询以消除查询解释器报告的低效率。这将为如何提高应用程序的效率提供良好的反馈，或者可能导致上述关系更好的规范化。

  • 为属性创建索引，在实践中，这些索引可用于大量事务。这可能非常有效，但它是在维护索引时降低大多数写入操作的速度，以便在使用索引时提高某些特定读取操作的速度。

  • 创建补充表以保存中间预计算结果以供将来查询使用。这很少是一个好主意，尤其是因为它完全违反了 DRY 原则；您现在必须想出一个策略来保持重复信息（原始数据和派生数据）同步，而当没有重复数据时，RDBMS 将尽其所能。

这些都不涉及在存储主要数据的表中搞乱。

于 2010-03-21T01:16:47.930 回答