こんにちは。
データエンジニアのKotaです。
初投稿ですが、お手柔らかにお願いします。

普段僕は自社プロダクトのデータ分析チームで、
ビッグデータ分析基盤の要件定義~運用まで一気通貫で作らせて頂いてます。

そこで今回議論したいのが、表題の件。

現場によっても、下手すれば現場内のDBによってもバラバラの型をしている日付カラム。
皆さんお持ちのDBでは、どちらの型になっているでしょうか？？

#議論したいと思ったきっかけ

かくいう僕も、この問題で先日上司と軽くバトりました。
まずはその話から簡単に触れます。ちなみにエンジンはMysqlです。

ある日、別の分析基盤を作っている後輩のDB設計書をレビューする機会がありました。メンバーは後輩・僕・上司の3人。
そこで後輩が、分析用一時テーブルの日付列のデータ型を以下の様にしていました。

カラム名	データ型
CREATE_TIME(作成日)	varchar(14)
UPDATE_TIME(更新日)	varchar(14)

恐らく一部マスタ系のテーブル以外はほぼ持っているであろうこのカラム。

これに対し、語気を強めてツッコミを入れたのが先輩です。

「ここの2つさ、datetime型にしてよ!!!」

お？そんな強く言うこと？
いや、てか別にvarcharで良くね？
むしろvarcharが良くね？と思ったのが僕。

その旨上司に伝えてみると、

**「いやいや絶対datetime型!!」**の一点張り。

その場で議論が始まるも、平行線。
ちなみに既存の分析基盤はdatetimeだったので、
しょうがなく僕が折れる形でdatetimeに決着しました。

#僕の言い分

事実だけ伝えられても「そっか...」って感じだと思うので、
お互いの主張の理由を見てみましょう。

まずは僕から。僕の主張の根拠は以下3つです。

①チューニングのしやすさ
②業務用DBとのフォーマット合わせ

①
僕が重視したのはこれです。
検索の際に関数を指定しなくて良くなるので非常に楽。
特に既存の分析用SQLなんかは、
件数が億に迫るテーブルから、1日分のデータを以下のように算出していました。

SELECT ...
FROM ...
WHERE DATE(RPAD(UPDATE_TIME,14,0)) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY) AND CURRENT_DATE();

ちなみにこれ以外に条件はありません。中にはこれに加え、結合を行っているものも複数あります。
WHERE条件で使用しているUPDATE_TIMEをdate型に変換+謎のRPAD関数と、
関数を2ネストかましています。(恐らく不良データ対策でしょう)
当然関数を使ってるのでインデックスは効きません。
それどころかこのテーブル、UPDATE_TIMEを第一項目としたインデックスすら付与していない始末。
既に件数が億近いテーブルからこの条件でデータ抽出。よく今までやってたな...って感じです。
UPDATE_TIMEがvarcharになれば、不必要にdate変換なんてしなくて良いので、
インデックス効くようになるし。RPADは知らん。作った人辞めてて理由は誰も知らん。地獄って感じ。

②こちらの理由もあります。うちの現場、UPDATE_TIMEの扱いがDBによって違います。

★業務用DB

カラム名	データ型
CREATE_TIME(作成日)	varchar(14)
UPDATE_TIME(更新日)	varchar(14)

★分析用DB

カラム名	データ型
CREATE_TIME(作成日)	datetime
UPDATE_TIME(更新日)	datetime

★分析結果可視化用DB

カラム名	データ型
CREATE_TIME(作成日)	datetime
UPDATE_TIME(更新日)	datetime

何で違うんでしょうね。作った人辞めてて理由は誰も知らん。地獄って感じ。
恐らく可視化の際に、BIツールでのデータソース読み込みで都合が悪そうだからdatetimeにしてるのかな...って感じはします。

今回後輩君はこの理由でvarcharにしたそうです。不良データなら可視化DBに移送する際にチェックできるし。だそうです。その通りだと思います。

#上司の言い分

一方、上司の言い分です。

①現行踏襲
②不良データへのリスク
③設計書見て、「日付入れてるんだな」って分かりやすい

①、③は聴き流してました。

②が彼のメイン主張。
僕のチューニングに対する言い分を聞いた上で、
「運用乗ってるし、何か変わったときに変なデータ入って処理が落ちるリスクがある」んだそう。
その辺の検証をする時間的余裕はない！って言われてしまったので、
それ以上何も言い返せず、この場は終わりました。

#モヤモヤする...。

あまりにモヤっとなのでここに書かせて頂きました。
またハードウェアに優しくない激重SQLが1つ出来上がってしまうのかと思うと...。

僕が経験してきた現場でも、ここの型にはバラツキがあったので気になります。どっちがより良いんでしょうか。

皆さんの現場ではここのデータ型、何にしていますか？
どんな理由があってその型にしていますか？

ぜひご教授頂けたら、とても嬉しいです。

最後まで見て頂いて、ありがとうございました。