Re:もうちょっと具体的に：re: Re:もうちょっと具体的に（えムナウさん）より：
私が好みなのはcom.execute()でストアドをよんでそのストアドのエラー値をRETURN_VALUEで拾うやり方です。
ストアド内でTransactionしていれば完璧に複数人数が使う業務に耐えられますし、SQLサーバーや.NetFrameWorkのException関係のコストも軽減できます。
データの操作はデータベース内で完結させる。昔、書いたような気がするのですが、忘れた。
私も、理想としては、そうしたい。理想では。そう。理想。。。
何が現実と違うのか。
Stored Procedure そのものがひとつの言語なので、ひとつのアプリケーションの中で複数の開発言語を使う。これが、本当に良いことなのだろうか、というのがひとつ。もちろん、SQL も、それはそれでひとつの言語なんだけど。
ああ。でも、後ろ向きな考え方だなぁ。
うん。千里の道も一歩から。今踏み出さないと、いつ踏み出すのか。
戯れ言は言っていられませんね。
ちゃっぴさんのコメントも、ふれてしまう。
re: ウェブだけじゃないのよ、SQL インジェクションは（ちゃっぴさん）より：
個人的には、DBMS の security 機能を利用した
より security に配慮した実装をやるべきではないのか？
でも、読めちゃいけない data が読めるとか
そういう問題は本来は code で解決する問題じゃ
無いような･･･
夏椰さんところ（スキーマわけによるセキュリティ対策 その２）で話されているように、スキーマをわけるなど、データベース自体がセキュリティを考えるのがよいでしょう。
いくら警戒しても、しすぎることはない。入力系の防御については、いろんな突破策が、後から後から出てくるでしょう。しかし、データ自体にアクセスできないのであれば、漏れることはないのですから。
ただ、泣き言に戻ってしまいますが、アプリケーションの設計をやって、コードを考えながら、データベースの設計やストアドの設計や、コーディングもやるのかぁ。。。
ん。。。いかに自分が安穏とした職場にいるか、よくわかりますです。。。
投稿日時 : 2007年1月18日 22:06