No.3
722
54
34pt
日付演算（○ヶ月後を求める、○日後を求める、○日間かを求める、○年○月のデータを対象にする）などがなかったり、数値から日付への変換処理が不要なら別に数値で管理してもいいと思います。
しかし、アプリ側で数値→日付、あるいは日付→数値変換処理を準備し、しかもシステム内の共通処理として持つのは、あまり効率的とは思えません。
各RDBMSも、日付型を実装し、操作性や性能改善もされています。そこであえて日付を数値で管理するというのいは、あまりメリットを感じないし、今後のシステム拡張性、あるいは一部分を異なるRDBMSで管理するなどでの移植性などでもデメリットが多いと思います。
No.1
5810
26pt
個人的にはバカというか嫌です。SQL92やSQL99で専用の型が用意されているんだから使うべきでしょう。
第一、メンテナンスするときに、型を見ただけでそれが日付や時刻を表すことが一目瞭然ですし。
でも、もしかしたらRDBMSの負荷をほんの少しでも下げるための工夫なのかも。
でもやっぱり見たときに素直にわかりやすいほうがいい。
確かにRDBMSとしては数値でそのまま扱えて便利でしょうが、RDBMSの外で使用する場合に結局変換しなければなりませんよね。ソートや比較時には有効なんでしょう、きっと。
クソ重ったいテーブルの中でチューニングの一環として数値型で定義されているのであれば、確かに納得です。
No.2
92813
5pt
数値型でも、どのような値を入れるかにもよります。
http://cocohome.hp.infoseek.co.jp/perl_ref/time.html
このような数値を格納するのは、馬鹿じゃないですかね。
-----
文字列として格納する設計も良くありますよ。
日時型を使うと落とし穴がありそうで個人的には怖いです。
Unix Time以外に入る数値型ってありますかね？
YYYYMMDDHHMISSで入ることを想定してbigintとか定義する人は大馬鹿ですか？
No.3
72254
ここでベストアンサー
34pt
日付演算（○ヶ月後を求める、○日後を求める、○日間かを求める、○年○月のデータを対象にする）などがなかったり、数値から日付への変換処理が不要なら別に数値で管理してもいいと思います。
しかし、アプリ側で数値→日付、あるいは日付→数値変換処理を準備し、しかもシステム内の共通処理として持つのは、あまり効率的とは思えません。
各RDBMSも、日付型を実装し、操作性や性能改善もされています。そこであえて日付を数値で管理するというのいは、あまりメリットを感じないし、今後のシステム拡張性、あるいは一部分を異なるRDBMSで管理するなどでの移植性などでもデメリットが多いと思います。
日付演算がなくても、当該カラムに条件をつけてSELECTする際のSQL文の可読性も落ちるのではないかと思います。
UnixTimeを見た瞬間に「ああこれは何月何日の何時何分何秒だよ」と言うことが、プログラマーはもちろんシステム利用者が言えるような世の中なら全然問題なさそうですね。
No.4
8010
18pt
確かに僕もバカだと思うし日付型で管理した方が良いと思っていますが、とあるDBで月上期下期などを表現するときに日付型で入れられない数値を組み込むことで対応しているのを見たことがあります。形式はVARCHAR2でした。
たとえば上期なら20080800（yyyymmdd）なんて言う感じで。
「なんか心情的に日付型はわかりにくい」なんて言う人はこの業界でも結構居たりしますしね〜。
納期や未来のあいまいな日付といったデータが格納されるカラムだと、YYYYMMDDにして年度末という表現を"20090332"と定義できるようにするのはアリかもしれません。
「自分が心情的にわかりにくい」という理由で、デメリットの多い設計にする奴は馬鹿なのかが気になります。
No.5
60
17pt
大量のデータ（数千万とか数億とか）を日付を条件に検索する要件がある時
「日付型の比較より数値での比較の方が高速である」という理由でこういった設計になる事が有るようです。
ただ、SQL上で日付演算をしようとするとこんな感じになって鬱になれる事請け合いですが...
申し訳ありません、日付ではなく日時型です。
確かに日付型の場合は確かに"可変長文字列(8)"とかやりたくなりますが、演算の時に結局不利になるんですよね。数値(8)でYYYYMMDDとしても、"20080819"と"20080719"の差って"100"じゃないんですよねー。
まだ数値型にして86400区切りのUnixTimeで日付を定義したほうがマシってなもんです。
質問も読んでみましたが、結局、ある一定条件でハイパフォーマンスが出せても、それ以外のところで割を食う可能性の高い設計、ってことなんですよねきっと。
pkb_wn
2008/08/17 20:42:13
1
2
1
2
1
14
12
日付演算がなくても、当該カラムに条件をつけてSELECTする際のSQL文の可読性も落ちるのではないかと思います。
UnixTimeを見た瞬間に「ああこれは何月何日の何時何分何秒だよ」と言うことが、プログラマーはもちろんシステム利用者が言えるような世の中なら全然問題なさそうですね。