2016-03-22 6 views
1

テーブルのデータを次のように保存していました。日付データ型のテーブルサイズを減らす方法は?

create table A 
(
    RecordDate date not null, -- 3 bytes 
    SomeNumber int not null, -- 4 bytes 
) 

表Aの約20,000レコードが、同じRecordDateで作成されますが、SomeNumberは異なります。そのため、RecordDateは多くのレコードに対して冗長になります。テーブルサイズを縮小する余地があると感じました。日付情報を失うことなくテーブルAのサイズをカットする方法はありますか?ありがとう。

+1

1日あたりの注文数は何ですか?何千ものデータがなければ、日付列の相対的なスペースが現代のデータベースに欠けてしまう状況を見ることはできません。また、あなただけの日付を格納したいと思いますか?あなたが時間を保存するかもしれないすべての注文の行がある場合、それは非常に有用な統計です。 –

+3

私はここに最適化の範囲を見ません。これが埋め込み型デバイスの一部であり、スペースの制限がある場合は、別のテーブルにその日の開始順と終了順の日付を格納することができますが、データを取得する際には悪夢になります。 – bansi

+0

1日あたり約20,000レコードが追加されています。 –

答えて

0

私のコメントによると、1日に20,000件の取引があっても、あなたの場合はそれほど努力する価値はないと思います。私は1日に何百万件もの取引をする価値がないと考えています。 「日付」フィールドは3バイトのデータを使用します。これはすでにデータベース内の最小のデータ型の1つです。

しかし、私は興味深い質問だと思います。

Bansiの提案は非常に効率的なソリューションです(最小注文番号と最大注文番号を持つ日付表を持っています)が、テーブルキーがなくてもデータを破損する可能性があります。壊れた。ある範囲内の日付を見つけるために各レコードに対して2つの計算を行わなければならないので、クエリ時間を大幅に増やすこともできます。

私のソリューションは、日付キーと日付を持つ次元モデリングスタイルの日付表です。取引テーブルには、参加するための日付キーが保存されます。このためには、日付キーは「smallint」タイプ(2バイト)でなければなりません。行ごとに1バイトを差し引いて、日付表そのもののために比較的わずかな量を節約します。

'smallint'を使用すると、あなたの日数は65,535日に制限されます。日数が連続している場合は〜180年に制限されます。

+1

ありがとうございました。あなたの提案に基づいて考えました。あなたたちは正しい、それを変更する価値がないかもしれない。すべての選択肢を表示していただきありがとうございます! –

関連する問題