2

株式市場のデータを MySQL に保存したいと考えています。約 6,000 の個別在庫を保管できます。それぞれに次のデータがあります。

Symbol    Date          Open      High    Low    Close    Volume
ABCD      2012-09-22    50.00     55.25   48.73  51.23    34,002,212

取引日ごとにエントリーします。

私の見方では、巨大なテーブルを作成するすべてのエントリで 1 つのテーブルを作成することも、1 つの株に対して 1 つのテーブルで 6,000 のテーブルを作成することもできます。新しいエントリは毎日追加されます。

最終的には、データベースにクエリを実行して、2 つの日付間の 2 つ以上のシンボルのデータを取得したいと考えています。

このデータを MySQL に保存する最良の方法は何ですか?

4

3 に答える 3

1

6000 個のテーブルの作成を動的に管理できる限り、最適化するクエリの種類に応じて、どちらのアプローチも使用できます。

6000 のテーブルの問題は、その SQL が醜い、またはきれいであるということではありません。（つまり、あなたは本当に気にしますか？）

1つのテーブルで動作するSQLは次のようになります

Select <columnslist> FROM ScripDataTable
Where  scripcode = '<YourChoice>'
And ....

6000テーブルで動作するSQLは次のようになります

Select <columnslist> FROM (Select tableName FROM TableDictionary
Where  tableName Like '%<YourChoice>%')
Where ....

テーブルに余分な列を追加することにした場合、スクリプトごとに 1 つのテーブルの問題が発生します。私は約 5 枚のスクリップの価格を Excel で維持しており、最近、取引所から公開された多くの統計を追加することにしました。スクリプトが 5 つあるので、手動で追加するのに 1 日かかりました。

于 2013-05-02T08:19:34.150 に答える
1

Symbol を主キーとする 1 つのテーブルのように聞こえます。これにより、Symbol にクラスター化されたインデックスが表示されます (速度が多少向上します)。

6000 のテーブルを持つことは悪い考えだと思います。あなたの Select クエリはあまりきれいではありません。

于 2012-09-22T19:28:40.193 に答える
0

あなたは間違いなく6000テーブルを望んでいません。:) 1 つのテーブルで確実にこれを処理できます。Symbol と Date にインデックスを作成することを検討するかもしれません。それがクエリの対象になるからです。それが役立つことを願っています。

于 2012-09-22T19:27:17.123 に答える