- 1 名前：nobodyさん mailto:sage [2009/01/23(金) 09:46:51 ID:???]
- ●過去ログ
Part1 - 【質問】 ASP.NETスレ 【議論】
pc5.2ch.net/php/kako/1040/10406/1040698263.html
【質問】ASP.NETスレ Part2【議論】
pc8.2ch.net/test/read.cgi/php/1111480331/
【質問】ASP.NETスレ Part3【議論】
pc11.2ch.net/test/read.cgi/php/1160355849/
【質問】ASP.NETスレ Part4【議論】
pc11.2ch.net/test/read.cgi/php/1184683786/ （dat落ち？）
あんまり需要ないのかもしれませんが。。。
- 643 名前：nobodyさん mailto:sage [2009/07/23(木) 16:11:21 ID:???]
- 分業が必要な規模のアプリの場合、
その複数のプログラマがみんな美しいSQL文を書けるわけじゃないし
マニュアル等々で均一化するのも大変
1人のデータベーススペシャリストに
美しいSQL文でストアド作らせてた方が効率いいだろ、と感じる
あと、ASPの場合、外部からのハックキングを想定せねばならず
データベースへのアクセス権限としてテーブルへの直アクセスを許したくない
- 644 名前：nobodyさん mailto:sage [2009/07/23(木) 16:15:12 ID:???]
- 仕様変更でDBのフィールドが一つ増えるたびに、
関係するクライアントアプリやASP.NETに記述したlinqをすべて書き直すなら、それでもいいんじゃね？
単一クエリなら問題ないが、1行の操作が他のテーブルに影響を与えるなら、
ストアドプロシージャやビューをフルに活用したほうが、
処理をDB内にカプセル化できるから、仕様が変更されても、
アプリケーションを変更する必要がないし他でも簡単に使いまわすことができる。
その典型例がDBを掃除するコード。
引数が必要ないからアプリ側に影響を与えないし、
ループして複数の行に対して処理するだろうからストアドのほうが高速だし、
トランザクションも明示的に処理ができる。
|
 |
