日付型をいい加減Char(8)とかでもつのをやめてほしい・・・

特に検索にて、日付のみしか持たない項目で、Indexを張って高速に日付の検索を行う目的などが無い限り、日付は日付型で持ってほしいですorz
(↑のもよほどの事が無い限り嫌です。理由は最後に。)

DataGridにぶち込むのに日付型に直してフォーマットかけたり、帳票の出力に合わせて、フォーマットをまたまた変えて表示する際に、文字列だとめんどいです。

SQLから引っ張ってくるときに、Date型に変えれば良いじゃんという意見もありますが、
そもそも取得処理ではデータ加工をしない方が良いと思っているのが私です。

これは、データの取得部分が処理に引っ張られるのは、( ‥) ン?っとなるからです。

必要であれば、使う側が加工して処理をすればいいのです。

そういった意味では、DBに格納するデータは、未加工のそのままの適切な型で格納されているのが個人的には望ましいです。

もっとも、日付型を文字列で持ちたいんだ。検索楽なんだぁ～っという場合は、素直にインデックス付の計算列もったりすれば良いんでない？っと思ってみたりします。
(Oracleだと、関数Indexとかになるんかな？)

いちよう↑のようなものまであるのに、それでも日付型を文字列で持つ意味がわからん・・・

計算列などを仮想列としてではなく、実体として持つと、HDDの容量がぁ～というレベルなら、そもそも計算列にインデックスを付ける付けない以前の問題だしなぁ～。

DBへの登録処理で高速化

さて、今の現場で入る前にそういえば夜間バッチでの処理を行う際に、
150カラム程度で数百万件程度のデーターを素早く登録したいといっていたので、
さらっとソースを眺めてどう作ろうかなぁ～
っと思ってたら・・・分散トランザクションが使えねー(´ρ`)

DBのコネクション管理クラスが分散トランザクションでのスレッド処理とか全く考慮に入れられてない・・・

どないしようか・・・

動いてる部分だから手出したらマッハで飛んできて文句言うだろうし・・・

(´－｀) ンー　その前にMSDTCとか入れていいのだろうか？
テスト環境の用意が出来るのだろうか・・・不安でならない。

スレッド使ったらそもそも文句垂れられそうだ・・・わかんねーとかいわれて・・・

どないしようか本当にorz

適当に作れませーんっとか言っておこうか激しく考え中。

そもそも面談でSQLでなんとか高速化をとかいってたのが、引っかかってたが実際に本当に引っかかった(´ρ`)

元の取り込み元がファイルとかなら、ファイルをガッツリ取り込むとかもできるんだが・・・