Question

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

我的要求是为多个股票代码存储“条形数据”（日期，开盘价，最高价，最低价，收盘价）。每个符号也可能有多个时间范围（例如Google Weekly bars和Google Daily bar）。

我当前的架构将大部分数据放在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

我们试图找到一个适当的数据库结构，用于长时间存储大量数据。以下解决方案是超过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

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

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

表现如何？我们可以在几毫秒内从服务器获取数据。请记住，数据库大小几乎是1太字节。

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

Answer 2

嗯，从积极的方面来说，你首先要求输入是有道理的。这使您领先于90％不熟悉数据库设计的人。

没有明确的外键关系。我认为timeframeID涉及symbolID？
目前还不清楚你怎么能以这种方式找到任何东西。阅读上述外键可以轻而易举地提高您的理解力。
您将时间范围数据存储为TEXT。从性能和可用性的角度来看，这是一个禁忌。
您当前的方案无法容纳最终会发生的股票拆分。最好在价格数据表和符号
open，high，low，close价格最好存储为十进制或货币类型，或者最好作为INTEGER字段存储存储除数的单独INTEGER字段，因为每个交易所允许的最小价格分数（美分，八美元等）。
由于您支持多个广告交易平台，因此您应支持多种货币。

如果所有这些看起来都不具有“建设性”，我道歉，特别是因为我现在太困了，建议一个更有用的选择。我希望上述内容足以让你顺利上路。

Answer 3

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

我还要注意，由于各种原因，股票代码会不时变化。这不是一个经常发生的事件，但它确实发生了。如果您正在考虑将数据作为时间序列处理，那么您应该知道这个问题，以便在它到来时（如果不是之前）处理它。如果你没有跟踪股票（你可能正在研究期货应用程序，比如说），那么这个建议可以用适量的盐来进行。

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

如果您计划查看特定符号的一系列数据，我建议您研究一下您将获得的性能。至少，确保您有适当的索引。

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

3 个答案: