36

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

私の要件は、複数の銘柄記号の「足データ」(日付、始値、高値、安値、終値) を保存することです。各シンボルには複数の時間枠がある場合もあります (例: Google Weekly バーと 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 を検索し、timeframeID が一致する OHLCV テーブルで選択を行います。

4

3 に答える 3

43

大量のデータを長期間保存するための適切なデータベース構造を見つけようとしました。以下のソリューションは、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/ ) から購入しました。

于 2010-01-14T08:30:54.503 に答える
30

良い面としては、最初に意見を求めるのは良識があります。これにより、データベースの設計に不慣れな 90% の人よりも優れています。

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

特に今は眠すぎて、より使いやすい代替案を提案できないため、これらすべてが「建設的」すぎるように思われない場合はお詫び申し上げます。上記があなたの道を歩むのに十分であることを願っています。

于 2009-10-06T05:16:10.813 に答える
4

不必要な複雑さのように思えますTimeframeが、それは私が理解できていない可能性があります;-) Timeframe は複数の OHLCV を持つことができますか? そうでない場合は、それらを統合することをお勧めします。

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

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

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

于 2009-10-06T08:15:18.460 に答える