質問: DateTime型の列にインデックスを付けるのは邪道?
回答: 何を思って「邪道でかも」と思ったのか分かりませんが、必要であるなら邪道ではありません。 「そもそも論はご遠慮」とかかれていますが、そもそも、何かの必要性がある場合にインデックスをつけるので、必要性があるなら邪道ではないと思います。(例えば、検索の時のキーになるや、結合のカラムとなる(秒まで入るならこれは無さそうですが・・・)など) インデックスの必要性がないカラムにインデックスをつけるのは、データ型に限らず邪道です。 インデックスをつけることによる弊害はご存知ですか?(例えば、InsertやUpdateの速度が落ちるとか、B-Treeインデックスの場合は、インデックスの偏りが考えられるなら、メンテナンスが必要など) 一般論として、このあたりの利点と不利な点を比べ、必要であるかを考えるのが良いかと思います。 ちなみに、当社のシステムでは同じような秒まで保存する列にインデックスをつけて運用しているテーブルもあります。 追加 >一般的に、文字列に対してならハッシュ値が生成されてインデックスがまんべんなく構築されていくものと理解しておりますが 残念ながら、この部分が誤解されておられます。 一般的にインデックスは、列の値そのままで作られます。文字列型だろうが数値型・DateTime型だろうが同じです。 ですので、その列に入っているデータにより偏りも出来ますし、Insert・Updateにより効率よいインデックスにならないこともあります。 ハッシュ値のようなものを使用していない証拠としては、もしハッシュ値の様なものを使用していた場合、前方一致検索や範囲検索・Order Byの並び替えにはインデックスが使用できないことになってしまいます。(インデックスが等価評価による絞込みにしか使えないことになります。)もちろんそのようなことはありませんので、違うことが分かります。もちろん、ハッシュ値を保存するインデックスを作れるDBMSもありますので、一概には言えませんが、その場合は使用方法が限定されることになります。 インデックスが偏ることは、DateTime型でなくても起こることがあります。DateTime型も同じですが、シリアル値を保存するような目的の列です。 例えば、伝票番号を保存する列ですが、これが数値型だった場合、当然ですが、小さな値から順に使われることが多いと思います。つまり、時間が経てばインデックスは偏りが出てしまうため、この偏りを平準化することをしないと効率的にインデックスが使えないことになります。(文字列型でも同じことが言えますね) DBMSによっては偏りを自動で平準化するような昨日が付いているものもあるかもしれませんが、Oracleの場合は、運用のメンテナンスとして、インデックスの再作成などにより、インデックスの偏りを平準化する必要があります。 ちなみに、インデックスの種類によっては、偏りが出ないものがあります。Oracleではビットマップ索引がそうです。ただしこれは、一般的な列に使用するものではなく、カーディナリティ(選択性)が低い(入るデータの種類が少ない。例えば性別。男女の2種類しか入らない)ような列にだけ使用すべきインデックスです。 当社のシステムで秒まで保存している列のことを言いましたが、これは作業日時を保存する列です。これは、作業日次ごとで集計を取る必要があるため、インデックスをつけています。また、インデックスのメンテナンスは、日次バッチ処理の中で、毎日再作成処理を入れています。これにより、インデックスの効率的な利用が出来るよう、気をつけています。(弊害として、データのファイルの内のデータの断片化が起こっていると思います。)