web-dev-qa-db-ja.com

過去の株価データを整理するためのデータベーススキーマ

過去の株価データを保存するためのデータベーススキーマを作成しています。私は現在、以下に示すようなスキーマを持っています。

私の要件は、複数の銘柄記号の「バーデータ」（日付、始値、高値、安値、終値）を保存することです。各シンボルには複数の時間枠がある場合があります（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を見つけて、timeframeIDが一致するOHLCVテーブルで選択を行います。

sqlsqliteschemastocks
31
nall

さて、良い面としては、最初に入力を求めるのは良識があります。これにより、データベース設計に不慣れな人の90％よりも先を行くことができます。

  • 明確な外部キー関係はありません。 timeframeIDはsymbolIDに関連していますか？
  • この方法で何を見つけることができるかは不明です。上記の外部キーを読むことで、少しの努力であなたの理解が飛躍的に向上します。
  • タイムフレームデータをTEXTとして保存しています。パフォーマンスと使いやすさの観点から、それはノーノーです。
  • 現在のスキームでは、最終的に発生する株式分割に対応できません。価格データテーブルとシンボルの間に間接層をさらに1つ追加することをお勧めします
  • open、high、low、close価格は、10進数型または通貨型として、またはできればINTEGERフィールドとして保存する方がよい許可される最小の価格の割合（セント、8ドルなど）は交換ごとに異なるため、個別のINTEGERフィールドに除数を格納します。
  • 複数の交換をサポートするため、複数の通貨をサポートする必要があります。

特に今は眠くてもっと使いやすい代替案を提案できないので、これらすべてがあまりにも「建設的」に思えない場合は、謝罪します。上記があなたをあなたの道に導くのに十分であることを願っています。

27
Michiel Buddingh

大量のデータを長期間保存できる適切なデータベース構造を見つけようとしました。以下の解決策は、6年以上の経験の結果です。現在、当社の定量分析には問題なく機能しています。

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

すべての取引商品は単一のテーブルに保存されます。また、シンボル、日付、時刻の列にクラスター化インデックスがあります。

日次データの場合、別のテーブルがあり、時間列は使用しません。ボリュームデータ型もintではなくbigintです。

パフォーマンス？数ミリ秒でサーバーからデータを取得できます。データベースのサイズはほぼ1テラバイトです。

KibotのWebサイトからすべての過去の市場データを購入しました： http://www.kibot.com/

34
boe100

Timeframeによって追加される値はわかりません-不必要な複雑さのように見えますが、それは私が理解していないものである可能性があります;-)タイムフレームは複数のOHLCVを持つことができますか？そうでない場合は、それらをマージすることをお勧めします。

また、株式ティッカーはさまざまな理由で時々変更されることにも注意してください。それは頻繁なイベントではありませんが、起こります。データを時系列として処理することを検討している場合は、問題が発生したときにそれを処理できるように、問題を認識しておく必要があります。株価を追跡していない場合（たとえば、先物アプリで作業している可能性があります）、このアドバイスは適切な量の塩を使用して行うことができます。

再び主に株式に関連しますが、分割は他の場所で言及されており、配当を検討することをお勧めします-株式の価格は通常、配当落ち日に配当額（またはより正確には現在価値）だけ下がるでしょう。確認された将来のキャッシュフローが理由であるかどうかはわかりません。権利の問題も楽しいことがあります。

特定のシンボルの一連のデータを見ることを計画している場合は、どのようなパフォーマンスが得られるかを調べることをお勧めします。少なくとも、適切なインデックスが設定されていることを確認してください。

4
Mike Woodhouse