一尘不染

用于组织历史库存数据的数据库架构

sql

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

我的要求是存储多个股票代码的“柱形数据”(日期,开盘价,高,低,收盘量)。每个交易品种也可能有多个时间范围(例如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);

这意味着我的查询当前类似于:查找给定符号/时间框架的时间框架ID,然后在时间框架ID匹配的OHLCV表上进行选择。


阅读 139

收藏
2021-03-17

共1个答案

一尘不染

好的,从积极的方面来说,您有很好的意识要先征求意见。这使您领先90%的不熟悉数据库设计的人。

  • 没有明确的外键关系。我认为它timeframeID与什么有关symbolID
  • 尚不清楚您将如何以这种方式找到任何东西。阅读上述外键应该毫不费力地极大地增进您的理解。
  • 您正在将时间范围数据存储为TEXT。从性能和可用性的角度来看,这是不行的。
  • 您目前的方案无法满足股票分割的需要,最终会发生这种情况。最好在价格数据表和交易品种之间添加一层间接层
  • openhighlowclose价格更好存储为小数或货币类型,或者,优选地,作为INTEGER与单独的字段INTEGER字段,其存储所述除数,作为最小价格分数(美分,一元等的八分)允许每交换而变化。
  • 由于您支持多种兑换,因此您应该支持多种货币。

对于所有这些似乎都不太“具有建设性”,我深表歉意,尤其是因为我现在太困了,无法提出一种更有用的替代方法。我希望以上内容足以让您踏上前进的道路。

2021-03-17