SQLでロジック
http://q.hatena.ne.jp/1162199668
一ヶ月ほど前にこの辺が賑やかだった。
ふと気になって昔の自分のコードを見てみると・・難解なSQLがあった。
どうしても表示が遅くなる箇所があって仕方なくDAOを使わずにSQLを直接書いた記憶がある。
ビューとサブクエリを使いながら正規表現検索をしている。コメントが少ししかないのでその時の自分の考えは不明だが、もうちょっと簡単にできそうだ。
で、こういうのは検索系をビューにまとめて更新系を関数で書いたらいいのかな。
ストアドプロシージャを使うと効率的になる場面ってピンとこない。
一時はSQLの本を何冊か買ったけど今はかなり忘れてるなぁ。
作成日時と更新日時という項目があります。
新規データの扱いをどう考え、設計しますか？
１．更新日時が空白データ。
２．作成日時と更新日時が同じデータ。
１、２でどちらが良いと思ったでしょうか？
これは、実に簡単ですが、大変なセンスの違いがでます。これを間違うようではシステムの設計は出来ない。
当面、設計者になるのはやめた方がいい。
前に作ったDBメモ帳は更新日付をnullにしてた。
してたというか、新規書き込みのみのデータなのか書き換えを行ったデータなのかを知りたかったから、上で言う2から1に変えたんだ。
作成日時と更新日時をイコールで判断するのはおかしなロジックだと思ったんだけど一般的なのかな。
前に普通の企業（？）に就職した人からDBのNOT EXISTSを使ったクエリを教えてくれって言われたことがあったり、外部に頼んだシステムが非常に謎なストアドプロシージャ（シーケンスからnextval等を取得する・・？何故に関数？）を使っていたり・・。
複雑なSQLを何の決まりもなく使ってるところが多いからこそ、反対意見が多いのかも。
・・とO/Rマッパーを考え疲れたので気分転換。
# メモ
http://blog.livedoor.jp/froo/archives/50450281.html
こういう世界もあるんだな。
自分の扱うものは速度が要求されるわけでもないし大人数で開発してるわけでもないから全く趣味の領域なんだけども。
