Схема базы данных для организации исторических данных запаса

Я создаю схему базы данных для хранения исторических данных запаса. В настоящее время у меня есть схема, как показано ниже.

Мои требования состоят в том, чтобы хранить "данные бара" (дата, открытие, высокий, низкий, закрытый объем) для нескольких символов запаса. Каждый символ может также иметь несколько таймфреймов (например, Google Weekly bars и Google Daily).

Моя текущая схема помещает большую часть данных в таблицу 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 для заданного символа/таймфрейма, затем сделайте выбор в таблице OHLCV, где совпадает идентификатор таймфрейма.

Ответы

Ответ 1

Ну, с положительной стороны, у вас есть здравый смысл сначала просить ввода. Это ставит вас перед 90% людей, незнакомых с дизайном базы данных.

  • Четких отношений с внешними ключами нет. Я полагаю, что timeframeID относится к symbolID?
  • Непонятно, как вы сможете найти что-нибудь таким образом. Чтение вышеперечисленных внешних ключей должно значительно улучшить ваше понимание с минимальными усилиями.
  • Вы сохраняете данные таймфрейма как TEXT. Из производительности, а также с точки зрения удобства использования, что нет-нет.
  • В вашей нынешней схеме не может быть размещено разделение акций, которое в конечном итоге произойдет. Лучше добавить еще один слой косвенности между таблицей данных цены и символом
  • open, high, low, close цены лучше сохраняются как десятичные или валютные типы или, предпочтительно, как поле INTEGER с отдельным полем INTEGER, хранящим делитель, как наименьшая цена (центами, восьмерками доллара и т.д.) разрешена для каждого обмена.
  • Поскольку вы поддерживаете несколько обменов, вы должны поддерживать несколько валют.

Я прошу прощения, если все это не кажется слишком "конструктивным", тем более что я слишком сонный прямо сейчас, чтобы предложить более полезную альтернативу. Я надеюсь, что этого достаточно, чтобы поставить вас на ваш путь.

Ответ 2

Мы попытались найти правильную структуру базы данных для хранения большого количества данных в течение длительного времени. Решение ниже - результат более чем шестилетнего опыта. В настоящее время он работает безупречно для нашего количественного анализа.

Мы смогли хранить сотни гигабайт внутридневных и ежедневных данных, используя эту схему в SQL Server:

 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 терабайт.

Мы купили все наши исторические рыночные данные с веб-сайта Kibot: http://www.kibot.com/

Ответ 3

Я не уверен, что добавлено значение Timeframe - это похоже на ненужное усложнение, но это может быть то, что я не могу понять;-) Может ли Timeframe иметь более одного OHLCV? Если нет, тогда я предлагаю объединить их.

Я хотел бы также отметить, что биржевые тикеры время от времени меняются по ряду причин. Это не частый случай, но это происходит. Если вы думаете о работе с вашими данными в виде временных рядов, вы должны знать об этой проблеме, чтобы вы могли справиться с ней, когда дело дошло, если не раньше. Если вы не отслеживаете акции (возможно, вы работаете в фьючерсном приложении, скажем), то этот совет может быть принят с соответствующим количеством соли.

Снова в основном для акций, расколы упоминаются в другом месте, и вы можете захотеть рассмотреть дивиденды - цена акций обычно будет уменьшаться на сумму дивидендов (или, точнее, ее текущую стоимость) на дату экс-дивиденда, которая может быть неверно истолкованы, если вы не знаете, что подтвержденный будущий денежный поток стал причиной. Проблемы с правами также могут быть интересными.

Если вы планируете просматривать серию данных для определенного символа, я бы предложил посмотреть, какую производительность вы собираетесь получить. По крайней мере, убедитесь, что у вас есть соответствующий индекс.