MySQLでもPostgreSQLでも何でも、日時を格納するためのデータ型が用意されているRDBMSで日時データを数値型で格納するように設計する奴ってバカなんですか?

回答の条件
  • 1人1回まで
  • 登録:2008/08/13 14:59:11
  • 終了:2008/08/20 12:30:57

ベストアンサー

id:chuken_kenkou No.3

chuken_kenkou回答回数722ベストアンサー獲得回数542008/08/13 23:41:42

ポイント34pt

日付演算(○ヶ月後を求める、○日後を求める、○日間かを求める、○年○月のデータを対象にする)などがなかったり、数値から日付への変換処理が不要なら別に数値で管理してもいいと思います。

しかし、アプリ側で数値→日付、あるいは日付→数値変換処理を準備し、しかもシステム内の共通処理として持つのは、あまり効率的とは思えません。

各RDBMSも、日付型を実装し、操作性や性能改善もされています。そこであえて日付を数値で管理するというのいは、あまりメリットを感じないし、今後のシステム拡張性、あるいは一部分を異なるRDBMSで管理するなどでの移植性などでもデメリットが多いと思います。

id:americanboss

日付演算がなくても、当該カラムに条件をつけてSELECTする際のSQL文の可読性も落ちるのではないかと思います。

UnixTimeを見た瞬間に「ああこれは何月何日の何時何分何秒だよ」と言うことが、プログラマーはもちろんシステム利用者が言えるような世の中なら全然問題なさそうですね。

2008/08/14 01:03:30

その他の回答(4件)

id:yoshifumi1975 No.1

yoshifumi1975回答回数58ベストアンサー獲得回数102008/08/13 16:05:42

ポイント26pt

個人的にはバカというか嫌です。SQL92やSQL99で専用の型が用意されているんだから使うべきでしょう。

第一、メンテナンスするときに、型を見ただけでそれが日付や時刻を表すことが一目瞭然ですし。

でも、もしかしたらRDBMSの負荷をほんの少しでも下げるための工夫なのかも。

でもやっぱり見たときに素直にわかりやすいほうがいい。

id:americanboss

確かにRDBMSとしては数値でそのまま扱えて便利でしょうが、RDBMSの外で使用する場合に結局変換しなければなりませんよね。ソートや比較時には有効なんでしょう、きっと。

クソ重ったいテーブルの中でチューニングの一環として数値型で定義されているのであれば、確かに納得です。

2008/08/13 18:14:37
id:ken33jp No.2

ken33jp回答回数928ベストアンサー獲得回数132008/08/13 19:25:37

ポイント5pt

数値型でも、どのような値を入れるかにもよります。

http://cocohome.hp.infoseek.co.jp/perl_ref/time.html

このような数値を格納するのは、馬鹿じゃないですかね。

-----

文字列として格納する設計も良くありますよ。

日時型を使うと落とし穴がありそうで個人的には怖いです。

id:americanboss

Unix Time以外に入る数値型ってありますかね?

YYYYMMDDHHMISSで入ることを想定してbigintとか定義する人は大馬鹿ですか?

2008/08/14 00:47:17
id:chuken_kenkou No.3

chuken_kenkou回答回数722ベストアンサー獲得回数542008/08/13 23:41:42ここでベストアンサー

ポイント34pt

日付演算(○ヶ月後を求める、○日後を求める、○日間かを求める、○年○月のデータを対象にする)などがなかったり、数値から日付への変換処理が不要なら別に数値で管理してもいいと思います。

しかし、アプリ側で数値→日付、あるいは日付→数値変換処理を準備し、しかもシステム内の共通処理として持つのは、あまり効率的とは思えません。

各RDBMSも、日付型を実装し、操作性や性能改善もされています。そこであえて日付を数値で管理するというのいは、あまりメリットを感じないし、今後のシステム拡張性、あるいは一部分を異なるRDBMSで管理するなどでの移植性などでもデメリットが多いと思います。

id:americanboss

日付演算がなくても、当該カラムに条件をつけてSELECTする際のSQL文の可読性も落ちるのではないかと思います。

UnixTimeを見た瞬間に「ああこれは何月何日の何時何分何秒だよ」と言うことが、プログラマーはもちろんシステム利用者が言えるような世の中なら全然問題なさそうですね。

2008/08/14 01:03:30
id:haruo-31 No.4

haruo-31回答回数80ベストアンサー獲得回数102008/08/14 02:54:55

ポイント18pt

確かに僕もバカだと思うし日付型で管理した方が良いと思っていますが、とあるDBで月上期下期などを表現するときに日付型で入れられない数値を組み込むことで対応しているのを見たことがあります。形式はVARCHAR2でした。

たとえば上期なら20080800(yyyymmdd)なんて言う感じで。

「なんか心情的に日付型はわかりにくい」なんて言う人はこの業界でも結構居たりしますしね〜。

id:americanboss

納期や未来のあいまいな日付といったデータが格納されるカラムだと、YYYYMMDDにして年度末という表現を"20090332"と定義できるようにするのはアリかもしれません。

「自分が心情的にわかりにくい」という理由で、デメリットの多い設計にする奴は馬鹿なのかが気になります。

2008/08/14 10:16:46
id:hituziotoko No.5

ひつじおとこ回答回数6ベストアンサー獲得回数02008/08/19 20:41:38

ポイント17pt

大量のデータ(数千万とか数億とか)を日付を条件に検索する要件がある時

「日付型の比較より数値での比較の方が高速である」という理由でこういった設計になる事が有るようです。

ただ、SQL上で日付演算をしようとするとこんな感じになって鬱になれる事請け合いですが...

http://q.hatena.ne.jp/1207912904

id:americanboss

申し訳ありません、日付ではなく日時型です。

確かに日付型の場合は確かに"可変長文字列(8)"とかやりたくなりますが、演算の時に結局不利になるんですよね。数値(8)でYYYYMMDDとしても、"20080819"と"20080719"の差って"100"じゃないんですよねー。

まだ数値型にして86400区切りのUnixTimeで日付を定義したほうがマシってなもんです。

質問も読んでみましたが、結局、ある一定条件でハイパフォーマンスが出せても、それ以外のところで割を食う可能性の高い設計、ってことなんですよねきっと。

2008/08/20 12:28:18
  • id:HISI
    もしかして、コボラーが作ったのでは・・・(苦笑)


    日時ではなくて日付であれば、私も文字列型(数値型ではないですが)をよく使っています。
    DATE型(DATETIME型)だと
    [売上日] DATE (あるいはDATETIME)
    [データ入力日] DATE (あるいはDATETIME)
    といった列に、INSERT処理を作るコーダーは現在日時をそのまま入れて(SYSDATE や GETDATE() や NOW()など)
    検索プログラムを作るコーダーは SELECT ... WHERE [売上日] = 'YYYY/MM/DD'
    なんて書いてヒットしなくなるのも嫌ですから。


    もっとも、仕様書へしっかり定義した上でコーディング時に見てもらうことが重要ではあります。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません