股票价格的数据库建模

时间:2013-03-23 14:30:18

标签: sql database database-design

我最近获得了适合的数据库建模任务 存储超过140家公司的股票价格。将收集数据 所有这些公司每天15分钟,每天8.5小时。问题我是 现在面对的是如何设置数据库以实现快速搜索/获取 鉴于此数据。

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

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

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

您对这类解决方案有何看法?我希望问题得到解释 详细说明,请告诉我。

非常感谢任何其他解决方案!

5 个答案:

答案 0 :(得分:4)

除了已经说过的内容之外,我想说明以下内容:不要使用“公司名称”或“Ticker Symbol”之类的东西作为主键。正如您可能会发现的那样,股票价格有两个经常被忽略的重要特征:

  • 某些公司可以在多个证券交易所上市,因此每个证券交易所的报价都不同。
  • 有些公司在同一个证券交易所多次报价,但以不同的货币报价。

因此,正确的通用解决方案应使用(ISIN,货币,证券交易所)三元组作为报价的标识符。

答案 1 :(得分:3)

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

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

如果它是OLAP应用程序(并且存储数十亿股票价格的系统听起来更像是OLAP应用程序),那么您设置的数据结构可能会更好地组织以存储预先聚合的数据值,甚至可以全部使用使用像OLAP cube这样的多维数据库,基于star schema

答案 2 :(得分:3)

考虑到你可能产生的大量记录,我认为你关注的是性能 - 140家公司* 4个数据点/小时* 8.5小时* 250个交易日/年意味着你正在查看大约120万个数据每年积分。

现代关系数据库系统可以在一个表中轻松处理这些记录(需要考虑一些重要因素) - 我没有看到存储100年数据点的问题。

所以,是的,您的初始设计可能是最好的:

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

在公司名称和日期上创建索引;这将允许您回答以下问题:

  • x公司的最高股价
  • y日期公司x的股价是多少
  • 日期y,股价最高的是什么

为了帮助防止出现性能问题,我构建了一个测试数据库,并使用示例数据填充它(像dbMonster这样的工具使这很简单),然后构建您(想到的)将针对真实系统;使用数据库系统的调优工具来优化这些查询和/或索引。

答案 3 :(得分:3)

将它们放入一张表中。现代数据库引擎可以轻松处理您指定的卷。

rowid | StockCode | priceTimeInUTC | PriceCode | AskPrice | BidPrice |体积

  • rowid:Identity UniqueIdentifier。
  • StockCode而非公司。公司有多种类型的袜子。
  • PriceTimeInUTC用于将任何日期时间标准化为特定时区。
  • 也是datetime2(更准确)。
  • PriceCode用于识别价格:期权/期货/ CommonStock,PreferredStock等
  • AskPrice是购买价格
  • BidPrice是售价。
  • 成交量(买入/卖出)可能对您有用。

另外,有一个StockCode表和一个PriceCode表。

答案 4 :(得分:-1)

这是一种蛮力方法。第二,你添加了可搜索的因素,它可以改变一切。更灵活和优雅的选项是星型模式,可以扩展到任何 数据量。我自己是一个私人聚会。