特に検索にて、日付のみしか持たない項目で、Indexを張って高速に日付の検索を行う目的などが無い限り、日付は日付型で持ってほしいですorz
(↑のもよほどの事が無い限り嫌です。理由は最後に。)
DataGridにぶち込むのに日付型に直してフォーマットかけたり、帳票の出力に合わせて、フォーマットをまたまた変えて表示する際に、文字列だとめんどいです。
SQLから引っ張ってくるときに、Date型に変えれば良いじゃんという意見もありますが、
そもそも取得処理ではデータ加工をしない方が良いと思っているのが私です。
これは、データの取得部分が処理に引っ張られるのは、( ‥) ン?っとなるからです。
必要であれば、使う側が加工して処理をすればいいのです。
そういった意味では、DBに格納するデータは、未加工のそのままの適切な型で格納されているのが個人的には望ましいです。
もっとも、日付型を文字列で持ちたいんだ。検索楽なんだぁ~っという場合は、素直にインデックス付の計算列もったりすれば良いんでない?っと思ってみたりします。
(Oracleだと、関数Indexとかになるんかな?)
いちよう↑のようなものまであるのに、それでも日付型を文字列で持つ意味がわからん・・・
計算列などを仮想列としてではなく、実体として持つと、HDDの容量がぁ~というレベルなら、そもそも計算列にインデックスを付ける付けない以前の問題だしなぁ~。
外部システムが文字列でもっていたらそれに引きずられるってことはありますね。
返信削除まあこの問題はかわいいじゃないですか。
今やってる火消案件はカラムが800あるテーブルがわんさかあります。
処理毎に使うカラムを変えるらしいです。
状態Aのカラムは100-150をつかって状態Bは150-200を使う、みたいなw
外部システムとの兼ね合いであれば、その部分だけ対象のプログラムなりが責任をもって
返信削除変換を行えばいいのかなぁ~っと個人的には思っております。
よくCSVで他システムと連携とか取り込みとか、あとは銀行その他の引き落としデータなり
連携部分はありますが、各プログラムが責任をもって各々形式に変えてもらえればいいのかなと。
ってかそういう各システムによる取り込みファイルのフォーマット変換などがあるからこそ、元データは正しい型で
いかようにでもフォーマット変換ができるようにというのが希望です。
んでついでにDBを直接みるような場合は、もうIndex付のViewでもこさえます。
それはさておき、火消しプロジェクトのDB酷いですね(´ρ`)
それ、私なら間違いなくノイローゼ一歩手前です。
いや一歩手前どころか、本気で精神に異常をきたす可能性がある。
そのプロジェクトは本気で触りたくないですわ(ノ_・、)シクシク