用于组织历史股票数据的数据库模式

Question

我正在创建一个用于存储历史股票数据的数据库架构。我目前有一个如下所示的架构。

我的要求是存储多个股票代码的“柱数据”（日期、开盘价、最高价、最低价、收盘量）。每个交易品种也可能有多个时间范围（例如 Google 每周柱和 Google 每日柱）。

我当前的架构将大部分数据放在 OHLCV 表中。我远不是数据库专家，我很好奇这是否太天真。非常欢迎有建设性的意见。

CREATE TABLE Exchange (exchange TEXT UNIQUE NOT NULL);

CREATE TABLE Symbol (symbol TEXT UNIQUE NOT NULL, exchangeID INTEGER NOT NULL);

CREATE TABLE Timeframe (timeframe TEXT NOT NULL, symbolID INTEGER NOT NULL);

CREATE TABLE OHLCV (date TEXT NOT NULL CHECK (date LIKE '____-__-__ __:__:__'),
    open REAL NOT NULL,
    high REAL NOT NULL,
    low REAL NOT NULL,
    close REAL NOT NULL,
    volume INTEGER NOT NULL,
    timeframeID INTEGER NOT NULL);

这意味着我目前的查询类似于：查找给定交易品种/时间帧的 timeframeID，然后在 timeframeID 匹配的 OHLCV 表上进行选择。

Answer 1

嗯，从积极的方面来说，你很明智地首先要求输入。这让您领先于 90% 不熟悉数据库设计的人。

• 没有明确的外键关系。我认为timeframeID 与symbolID 相关？
• 目前尚不清楚您如何能够以这种方式找到任何东西。阅读上述外键应该可以毫不费力地大大提高您的理解力。
• 您将时间范围数据存储为TEXT。从性能和可用性的角度来看，这是不行的。
• 您当前的方案无法适应股票拆分，这最终会发生。最好在价格数据表和符号之间再增加一层间接性
• open、high、low、close 价格最好存储为十进制或货币类型，或者最好作为 INTEGER 字段与单独的 INTEGER 字段存储除数，作为最小价格允许的分数（美分、八分之一美元等）因交易所而异。
• 由于您支持多种交易所，因此您应该支持多种货币。

如果所有这些看起来不太“有建设性”，我深表歉意，尤其是因为我现在太困了，无法提出更有用的替代方案。我希望以上内容足以让您上路。

Answer 2

我不确定Timeframe 增加了什么价值 - 这似乎是一个不必要的复杂问题，但这可能是我无法理解的事情 ;-) 时间框架可以有多个 OHLCV 吗？如果没有，那么我建议将它们合并。

我还要指出，股票代码不时会因多种原因发生变化。这不是一个经常发生的事件，但它发生了。如果您正在考虑将数据作为时间序列来处理，您应该意识到这个问题，以便您可以在它出现时（如果不是之前）处理它。如果您不跟踪股票（例如，您可能正在开发期货应用程序），那么可以使用适量的盐来采纳此建议。

同样主要与股票相关，其他地方已经提到了拆分，您可能需要考虑股息 - 股票价格通常会在除息日下跌股息金额（或更准确地说是其现值），这可能如果您不知道确认的未来现金流是原因，则会被误解。权利问题也可以很有趣。

如果您打算查看特定符号的一系列数据，我建议您查看您将获得什么样的性能。至少，确保您有适当的索引。

Answer 3

我们试图找到一个合适的数据库结构来长期存储大量数据。下面的解决方案是 6 年多经验的结晶。它现在可以完美地用于我们的定量分析。

我们已经能够在 SQL Server 中使用这种方案存储数百 GB 的日内和每日数据：

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

所有交易工具都存储在一个表格中。我们还有一个关于符号、日期和时间列的聚集索引。

对于每日数据，我们有一个单独的表格，不使用时间列。卷数据类型也是 bigint 而不是 int。

性能？我们可以在几毫秒内从服务器中获取数据。请记住，数据库大小几乎是 1 TB。

我们从 Kibot 网站购买了所有历史市场数据：http://www.kibot.com/