まず、これに関して部分的な質問がありますが、それは私が求めていることとは正確には異なります。
私の質問は、SubSonicの機能と Rob Connery の優れたビデオを見た後、質問する必要があるということです。このようなツールを使用してインライン クエリを実行しますか、それともストアド プロシージャの呼び出しを使用してクエリを実行しますか?
ロブの仕事を最小限に抑えたくはありませんが (それは素晴らしいことだと思います)、新しいプロジェクトを開始する必要があり、私はその真っ只中にいるので、この理由についてあなたの意見が欲しいだけです。SubSonic (または NHibernate などの他の同様のツール) を使用するか、単純な方法であっても常にストアド プロシージャを呼び出すメソッドを続行します。
Select this, that from myTable where myStuff = StackOverflow;
同じデータベースに依存する複数のアプリケーションがある場合、ストアド プロシージャは最適です。複数の場所ではなく、一度にクエリ ロジックを定義して維持できます。
一方、ストアド プロシージャ自体がデータベース内でごちゃごちゃになってしまうのは非常に簡単です。ほとんどのシステムには、ストアド プロシージャを論理的に整理する適切な方法がないからです。また、バージョン管理や変更の追跡がより困難になる可能性があります。
どちらかである必要はありません。単純なクエリの場合は、SubSonic クエリ ツールを使用します。より複雑な場合は、ストアド プロシージャを使用してコレクションを読み込むか、結果からデータセットを作成します。
ここを参照してください: SQL をストアド プロシージャとコードに保持することの長所と短所は何ですか。ここではSubSonic とストアド プロシージャを参照してください。
インラインクエリとストアドプロシージャを組み合わせて実行しました。必要に応じて変更を加えるのに最適な場所が得られるため、ストアドプロシージャ/ビューのアプローチの方が好きです。インラインクエリがある場合は、常にコードを変更してインラインクエリを変更してから、アプリケーションを再ロールする必要があります。また、複数の場所にインラインクエリがある場合があるため、1つのストアドプロシージャよりもはるかに多くのコードを変更する必要があります。
次に、ストアドプロシージャにパラメータを追加する必要がある場合でも、とにかく多くのコードを変更します。
もう1つの注意点は、ストアドプロシージャの背後でデータが変更される頻度です。ここでは、正規化されたテーブルに分割される可能性のあるサードパーティのテーブルがあるか、テーブルが廃止されます。その場合、ストアドプロシージャ/ビューにより、その変更への露出を最小限に抑えることができます。
また、ストアドプロシージャなしでアプリケーション全体を作成しました。3つのクラスと10ページがあり、まったく価値がありませんでした。そのやり過ぎ、または正当化できる場合があると思いますが、それはあなたの個人的な意見や好みにも帰着します。
私は個人的に厳格な規則に従うつもりはありません。確かに、開発段階では、クエリをすばやく変更できるようにしたいので、インライン化します。
その後、次の 2 つの利点があるストアド プロシージャに移行します。他にもあると思いますが、これらの2つが私を魅了します。
1/ ストアド プロシージャは、データとそのデータを 1 点で操作/抽出するためのコードをグループ化します。これにより、DBA は既知の要因に基づいて最適化できるため、DBA の負担が大幅に軽減されます (アプリが DBA を保証するのに十分な大きさであると仮定した場合)。
DBA の大きな問題の 1 つは、アドホック クエリです (特に、フル テーブル スキャンが何であるかを知らない道化師による)。DBA は、データベースを調整できる一貫性のある優れたクエリを好みます。
2/ ストアド プロシージャには、データベースに残すのが最適なロジックを含めることができます。DB2/z で数十行のストアド プロシージャを見てきましたが、クライアントがコーディングする必要があるのは、「そのリストをください」のような 1 行だけです。
「そのリスト」のロジックはデータベースに保存されるため、DBA は、クライアント コードを侵害したり変更したりすることなく、その保存方法と抽出方法を自由に変更できます。これは、オブジェクト指向言語を以前よりも「クリーン」にしたカプセル化に似ています。
ストアドプロシージャに実際のロジック（変数、カーソルなど）が含まれていない限り、インラインSQLを使用することをお勧めします。最近、LINQ to SQLを使用しており、生成されたクラスを取得して、事前定義された一般的なlinqクエリを持つ部分クラスを追加しています。これにより、開発が迅速化されると思います。
編集：私はこれのためにダウンモッドされるつもりだと知っています。外部キーやストアドプロシージャについて話し合うと、ダウンモッドになります。DBAには雇用保障が必要だと思います...
その1つのアプリケーションからのみデータベースにアクセスする予定ですか？
そうでない場合は、データベースへの一貫したインターフェイスを使用できるように、ストアドプロシージャを使用することをお勧めします。
変更が必要な場合、アプリケーションの配布に多額の費用がかかりますか？
その場合は、サーバーで変更できるストアドプロシージャを使用する方が適切であり、それらの変更を配布する必要はありません。
データベースのセキュリティについてまったく心配していますか？
その場合は、ユーザーにテーブルへの直接アクセスを許可する必要がないように、ストアドプロシージャを使用することをお勧めします。
アプリケーションの外部で使用またはアクセスされないシステムのために、幅広い対象者がいない小さなアプリケーションを作成している場合は、インラインSQLで問題ない可能性があります。
ストアドプロシージャの利点（私の考えでは）
ストアド プロシージャは、データとそのデータを 1 点で操作/抽出するためのコードをグループ化します。これにより、DBA は既知の要因に基づいて最適化できるため、DBA の負担が大幅に軽減されます (アプリが DBA を保証するのに十分な大きさであると仮定した場合)。
ストアド プロシージャには、データベースに残すのが最適なロジックを含めることができます。DB2/z で数十行のストアド プロシージャを見てきましたが、クライアントがコーディングする必要があるのは、「そのリストをください」のような 1 行だけです。
私が見つけたストアド プロシージャを使用する最大の利点は、ロジックを変更したい場合、インライン クエリの場合、すべての場所に移動して変更し、すべてのアプリケーションを再ロールする必要があることですが、ストアド プロシージャの変更の場合は一箇所だけ必要。
したがって、明確なロジックがある場合はインライン クエリを使用してください。それ以外の場合は、ストアド プロシージャを優先します。
Subsonic では、インライン、ビュー、およびストアド プロシージャを使用します。サブソニックはデータ アクセスを容易にしますが、サブソニック クエリでは何もできません。最新バージョンですが、2.1 は改善されています。
基本的な CRUD 操作の場合、インライン SQL は簡単です。より複雑なデータが必要な場合は、ビューを作成する必要があり、そのビューに対してサブソニック クエリを実行します。
ストアド プロシージャは、より難しいデータ計算とデータ検索に適しています。通常、セットベースの検索は、手続き型処理よりも常に高速です。
現在の Subsonic アプリケーションは、3 つのオプションすべてを使用して素晴らしい結果を出しています。