- PR -

主キーの設定について

投稿者投稿内容
甕星
ぬし
会議室デビュー日: 2003/03/07
投稿数: 1185
お住まい・勤務地: 湖の見える丘の上
投稿日時: 2005-11-09 14:16
年月日を3つのフィールドに分けて格納するのは、月や年をまたいだ範囲検索が必要になった場合、致命的に問題になるので避けたほうが良いかと。例えば4月20日から5月15日まで検索しろとか言われたとき、途方にくれませんか?無いと言い切れるのなら止めませんけど・・・。

DBのインデックスには木構造が使われることが多いです。木を辿って一致するところを見つけたら、それより右側にあるノードは全て大きいと見なせます。不等号での検索も、等号での検索も処理コスト上はほとんど等価です。

特定範囲内のデータを検索する場合、不等号での比較を2回行うので、等号で検索した場合より多くのコストを払うことになるでしょう。ですが、ループの中で何千回も比較を繰り返すわけではありません。それによるコストの増加はたかが知れています。少なくとも索引が適切に設定されている限りはね。

文字型ではなく日付型を使って格納する場合のメリットは、日付を日付として扱える事でしょう。曜日を取得したり、書式を指定したり、経過日数を算出したりといった処理は、文字列の状態では出来ませんからね。文字列演算して分割すればよいといっても、その為に記述するコード量は確実に増加するし、プログラムコードは無料じゃないですからね。

#日付は日付型に、日時型をプライマリキーにするなら慎重に・・・


[ メッセージ編集済み 編集者: 甕星 編集日時 2005-11-09 14:23 ]
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-11-09 14:52
がるです。
引用:

甕星さんの書き込み (2005-11-09 14:16) より:
年月日を3つのフィールドに分けて格納するのは、月や年をまたいだ範囲検索が必要になった場合、致命的に問題になるので避けたほうが良いかと。例えば4月20日から5月15日まで検索しろとか言われたとき、途方にくれませんか?無いと言い切れるのなら止めませんけど・・・。


ををそういう検索パターンもあるですね。
確かにそのケースの場合だと(そうじゃなくても、って話もあるですが)
日付型に一日の長がありそうな。

引用:

DBのインデックスには木構造が使われることが多いです。木を辿って一致するところを見つけたら、それより右側にあるノードは全て大きいと見なせます。不等号での検索も、等号での検索も処理コスト上はほとんど等価です。
特定範囲内のデータを検索する場合、不等号での比較を2回行うので、等号で検索した場合より多くのコストを払うことになるでしょう。ですが、ループの中で何千回も比較を繰り返すわけではありません。それによるコストの増加はたかが知れています。少なくとも索引が適切に設定されている限りはね。


んっと。このあたりがちと「DBMSをガツガツ叩いてない」部分があるので
疑問というか質問なんですが。
やっぱり「体感するほど違わない」ものなんでしょうか?
# 現実問題、マシン性能からして「気にするなぃ」程度だと思ってはいるのですが。

引用:

文字型ではなく日付型を使って格納する場合のメリットは、日付を日付として扱える事でしょう。曜日を取得したり、書式を指定したり、経過日数を算出したりといった処理は、文字列の状態では出来ませんからね。文字列演算して分割すればよいといっても、その為に記述するコード量は確実に増加するし、プログラムコードは無料じゃないですからね。


ですねぇ。

概ねもやもやしていた疑問が氷解しました。
ありがとうございます & 便乗してしまってすみませんでした。

スキルアップ/キャリアアップ(JOB@IT)