5

我最近接到了一项任务，要为一个适合存储 140 多家公司的股票价格的数据库建模。所有这些公司每天每 15 分钟收集一次数据，持续 8.5 小时。我现在面临的问题是如何设置数据库以在给定这些数据的情况下实现快速搜索/获取。

一种解决方案是将所有内容存储在一个包含以下列的表中：

| Company name | Price | Date | Etc... |

或者我可以为每家公司创建一个表格，只存储价格和收集数据的日期（以及 atm 未知的其他参数）。

您对这些解决方案有何看法？我希望问题得到足够详细的解释，否则请告诉我。

任何其他解决方案将不胜感激！

4

5 回答 5

6

鉴于您可能生成大量记录，我认为您担心性能 - 140 家公司 * 4 个数据点/小时 * 8.5 小时 * 250 个交易日/年意味着您每年要查看大约 120 万个数据点.

现代关系数据库系统可以在单个表中轻松处理这么多记录 - 受一些重要考虑因素 - 我认为存储 100 年的数据点没有问题。

所以，是的，你的初始设计可能是最好的：

公司名称 | 价格 | 日期 | 等等... |

创建公司名称和日期的索引；这将允许您回答以下问题：

  • x公司的最高股价是多少
  • 公司 x 在 y 日的股价是多少
  • 在第 y 日，最高股价是多少

为了帮助防止性能问题，我会构建一个测试数据库，并用示例数据填充它（dbMonster等工具使这变得容易），然后构建您（认为您）将针对真实系统运行的查询；使用数据库系统的调优工具来优化这些查询和/或索引。

于 2013-03-23T15:08:18.407 回答
6

除了已经说过的话，我想说以下几点：不要使用“公司名称”或“股票代码”之类的东西作为您的主键。您可能会发现，股票价格有两个经常被忽视的重要特征：

  • 有些公司可以在多个证券交易所报价，因此每个证券交易所的报价不同。
  • 一些公司在同一证券交易所多次报价，但使用不同的货币。

因此，一个适当通用的解决方案应该使用（ISIN、货币、证券交易所）三元组作为报价的标识符。

于 2014-01-06T13:56:20.913 回答
4

第一个更重要的问题是将针对该表执行的查询的类型和使用模式是什么。这是一个在线事务处理 (OLTP) 应用程序，其中绝大多数查询是针对单个记录，还是最多针对一小组记录？或者是在线分析处理应用程序，其中大多数查询需要读取和处理大量数据以生成聚合并进行分析。这两种非常不同类型的系统应该以不同的方式建模。

如果它是第一种类型的应用程序 (OLTP)，那么您的第一个选项会更好，但是查询的使用模式和类型对于确定要放置在表上的索引类型仍然很重要。

如果它是一个 OLAP 应用程序（并且存储数十亿股票价格的系统听起来更像一个 OLAP 应用程序），那么您设置的数据结构可能会更好地组织以存储预先聚合的数据值，甚至可以一直使用基于星型模式的多维数据库，如OLAP 多维数据集。

于 2013-03-23T15:01:06.300 回答
3

把它们放在一张桌子上。现代数据库引擎可以轻松处理您指定的那些卷。

行号 | 股票代码 | 价格时间InUTC | 价格代码 | 询价 | 投标价格 | 体积

  • rowid：身份唯一标识符。
  • 股票代码而不是公司。公司有多种类型的袜子。
  • PriceTimeInUTC 是将任何日期时间标准化为特定时区。
  • 还有 datetime2 （更准确）。
  • PriceCode 用于识别价格：期权/期货/CommonStock、PreferredStock 等
  • AskPrice 是买入价
  • BidPrice 是销售价格。
  • 交易量（用于买入/卖出）可能对您有用。

分别有一个 StockCode 表和一个 PriceCode 表。

于 2013-03-23T15:19:32.313 回答
-2

那是蛮力方法。第二次添加可搜索因素它可以改变一切。一个更灵活和优雅的选择是星型模式，它可以扩展到任何数量的数据。我是一个私人团体，我自己也在做这件事。

于 2013-06-12T20:26:14.397 回答