日付型と日付をあらわす文字列（または整数）
日付型と日付文字列型の使い分け
理想的には 日付型と日付文字列（整数）はデータドメインで使い分ける。
日付型は日付文字列を拡張したデータドメイン。すなわち、いくつかの制約と専用メソッドを持った データドメイン と考えることができる。
もし簡単に使い方を分類するならば日付文字列型の場合には リテラル、固有名詞に近いイメージ、
日付型は変数や未編集の素データ（バイナリ）に近いイメージ。
そして SQL で置き換えると条件述語に使用する列なら
各種日付関数が変換なしに使用できる日付型。再フォーマットが不要の参照列にしか使わないなら
日付文字列型。という具合な使い分けになるだろうか。
仕様が流動的に変わるプロジェクトでは一般的には管理を簡略化するためにも日付および日時は日付型で極力統一することが望ましい。
これは、日付文字列型で問題ないと想定していた設計が開発中盤頃になってから日付型として使いたいという仕様変更が
良くあることに対しての保険でもある。ただ、常に日付型に統一するようにするというのも融通が利かないので、しっくりとこない。やはり選別には経験に基づいた勘が頼りのような気がする。
日付文字列型を使用する例としては論理的に遠隔地のシステムからの入力データで
データの内容も信用できない場合のステージング領域用、レガシーシステムからのデータ、
別システム連携の中継用のデータエリアに使用することなどが考えられる。
また、古いシステムには日付として 9999/99/99 や 0000/00/00、0000/01/01 などに特別な意味を持たして使っているシステムも少なくはない。そして Oracle は正しい日付文字列しか日付型として受け付けてくれない。
日付型と日付文字列 それぞれのメリット
日付型のメリット
日付・時刻として正しい書式と内容の保証（うるう年など）
タイムゾーン、末日、曜日、切捨てなどの日付算術処理や変換
元号（年号）や各種日付のフォーマッティング
期間型のサポート
例えば ADD_MONTHS、MONTHS_BETWEEN、LAST_DAY、TRUNC 関数などの日付処理は条件述語に頻繁に登場する常連関数である。また曜日名の取得にも TO_CHAR（日付） が利用できる。
日付文字列型（数値）のメリット
時分秒のデータ (Oracle には時刻だけの型がない）
日時としての制約がない（ファジーな記述も共存もできる）
データの インポート、SQL*Loader 処理が少し速い。
日時としての制約がない
以下の例は定型的な日付 DATE/TIMESTAMP というよりも 日付の 文字列／数字 の意味合いが強い。
日時ではなく、そのエンティティの文字属性と読み替える方が自然かもしれない。
日付文字列には日時属性というよりも文字属性に近いということになる。
9999/99/99 または 0000/00/00 (※)
26:00
14 時頃
午前中
明日
(※) サーバーの性能が向上し UI が充実している現在では、ある値に特別な意味を持たせて入力操作の短縮化やレコード長を縮める手法は良いアイディアと思えない。（パンチャーの方々が使用しているような特別なシステムは例外）
関連事項
