私はストアドプロシージャのファンではありません
ストアドプロシージャは、次の理由でより保守しやすくなっています。* SQLを変更するたびに、C＃アプリを再コンパイルする必要がない
データ型が変更されたとき、または余分な列を返したいときなど、とにかくそれを再コンパイルすることになります。アプリの下からSQLを「透過的に」変更できる回数は全体としてかなり少ないです
- SQLコードを再利用することになります。
C＃を含むプログラミング言語には、関数と呼ばれるこの驚くべき機能があります。これは、複数の場所から同じコードブロックを呼び出すことができることを意味します。すばらしい！次に、再利用可能なSQLコードをこれらのいずれかに配置できます。または、本当にハイテクを取得したい場合は、それを実行するライブラリを使用できます。それらはオブジェクトリレーショナルマッパーと呼ばれ、最近ではかなり一般的だと思います。
コードの繰り返しは、保守可能なアプリケーションを構築しようとしているときに実行できる最悪のことです！
同意しました。これが、storedprocsが悪いことである理由です。 SQLをSQLのブロックに変換するよりも、コードを関数にリファクタリングおよび分解（小さな部分に分割）する方がはるかに簡単ですか？
4つのWebサーバーと同じSQLコードを使用する多数のWindowsアプリがあります。SQlコードに小さな問題があることに気付いたので、プロシージャを1か所で変更するか、コードをすべてにプッシュします。 Webサーバーの場合は、すべてのWindowsボックスにすべてのデスクトップアプリを再インストールします（クリックすると役立つ場合があります）
Windowsアプリが中央データベースに直接接続しているのはなぜですか？それはまさにそこにある巨大なセキュリティホールのようであり、サーバー側のキャッシングを除外するためのボトルネックです。 WebサービスまたはWebサーバーと同様の方法で接続する必要がありますか？
では、1つの新しいsproc、または4つの新しいWebサーバーをプッシュしますか？
この場合、それは 1つの新しいsprocをプッシュする方が簡単ですが、私の経験では、「プッシュされた変更」の95％は、データベースではなくコードに影響します。その月に20個のアイテムをウェブサーバーにプッシュし、1個をデータベースにプッシュする場合、代わりに21個のアイテムをウェブサーバーにプッシュし、ゼロをデータベースにプッシュしても、ほとんど失うことはありません。
コードレビューがより簡単になります。
方法を説明できますか？わかりません。特に、sprocはおそらくソース管理されていないため、WebベースのSCMブラウザなどを介してアクセスすることはできません。
その他の短所：
Storedprocはデータベースに存在し、外部にはブラックボックスとして表示されます。それらをソース管理に入れたいという単純なことは悪夢になります。
真剣な努力の問題もあります。いくつかのフォーラムを構築するのに700万ドルかかる理由をCEOに正当化しようとしている場合は、すべてを100万の層に分割するのが理にかなっているかもしれませんが、それ以外の場合は、すべての小さなものにstoredprocを作成することは、メリット。