SQL をストアドプロシージャとコードに保持することの長所と短所は何ですか [終了]

https://stackoverflow.com/questions/15142

08-06-2019
|

質問

SQL を C# ソースコードまたはストアドプロシージャ内に保持することの利点と欠点は何ですか?私たちが取り組んでいるオープンソースプロジェクト (C# ASP.NET フォーラム) について友人とこの件について話し合っています。現時点では、データベースアクセスのほとんどは、C# で SQL インラインを構築し、SQL Server DB を呼び出すことによって行われます。そこで私は、この特定のプロジェクトにとってどれが最適かを確立しようとしています。

これまでのところ、私は次のものを持っています：

コード内での利点:

メンテナンスが容易 - クエリを更新するために SQL スクリプトを実行する必要がありません。
別の DB への移植が容易 - 移植するためのプロシージャが不要

ストアドプロシージャの利点:

パフォーマンス
安全

解決

私はストアドプロシージャのファンではありません

ストアドプロシージャは、次の理由により保守しやすくなります。* SQL を変更したいときに C# アプリを再コンパイルする必要はありません

データ型が変更された場合、または追加の列を返したい場合など、いずれにしても再コンパイルすることになります。アプリの下から SQL を「透過的に」変更できる回数は全体的にかなり少ないです

結局 SQL コードを再利用することになります。

C# を含むプログラミング言語には、関数と呼ばれる驚くべき機能があります。つまり、同じコードブロックを複数の場所から呼び出すことができます。すばらしい！その後、再利用可能な SQL コードをこれらの 1 つに入れることができます。あるいは、本当に高度な技術を使用したい場合は、それを行うライブラリを使用することもできます。これらはオブジェクトリレーショナルマッパーと呼ばれるもので、最近ではかなり一般的になっていると思います。

コードの繰り返しは、保守可能なアプリケーションを構築しようとするときに最もやってはいけないことです。

同意します。だからこそ、storedproc は悪いことなのです。コードを関数にリファクタリングして分解 (小さな部分に分割) するほうが、SQL を関数に分割するよりもはるかに簡単です。SQL のブロック?

4 つの Web サーバーと、同じ SQL コードを使用する多数の Windows アプリがあります。SQL コードに小さな問題があることに気付きました。それでは、どうしますか...1 か所でプロシージャを変更するか、コードをすべての Web サーバーにプッシュし、すべての Windows ボックスにすべてのデスクトップアプリを再インストールします (1 回クリックすると役立つ場合があります)。

Windows アプリが中央データベースに直接接続しているのはなぜですか?これは巨大なセキュリティホールであり、サーバー側のキャッシュを排除するボトルネックのように思えます。Web サービスまたは同様の Web サーバーを介して接続すべきではないでしょうか?

では、1 つの新しい sproc をプッシュしますか、それとも 4 つの新しい Web サーバーをプッシュしますか?

この場合、それはは新しい sproc を 1 つプッシュする方が簡単ですが、私の経験では、「プッシュされた変更」の 95% はコードに影響し、データベースには影響しません。その月に 20 個のデータを Web サーバーにプッシュし、1 個をデータベースにプッシュする場合、代わりに 21 個のデータを Web サーバーにプッシュし、ゼロをデータベースにプッシュしても、ほとんど損失は発生しません。

コードレビューがより簡単に。

どうやって説明してもらえますか？これはわかりません。特に sproc はおそらくソース管理に含まれていないため、Web ベースの SCM ブラウザなどを介してアクセスできないことがわかります。

さらに短所:

Storedproc はデータベース内に存在しますが、外部からはブラックボックスとして見えます。ソース管理にそれらを置きたいというような単純なことが悪夢になります。

努力の問題もあります。すべてを次のように分解することは理にかなっているかもしれません百万層 CEO にフォーラムを構築するのに 700 万ドルもかかった理由を正当化したい場合は、そうでない場合、あらゆる些細なことのために Storedproc を作成することは、何の利益もない余分なロバの仕事にすぎません。

他のヒント

これは現在、ここの他のいくつかのスレッドで議論されています。私は一貫してストアドプロシージャの支持者ですが、Linq to Sql に関するいくつかの優れた議論も提示されています。

コードにクエリを埋め込むと、データモデルと緊密に結合されます。ストアドプロシージャは、契約上のプログラミングの優れた形式です。つまり、ストアドプロシージャの入力と出力によって表される契約が維持される限り、DBA はプロシージャ内のデータモデルとコードを自由に変更できます。

クエリが管理しやすい中央の 1 つの場所ではなく、コードに埋め込まれている場合、実稼働データベースのチューニングは非常に困難になることがあります。

[編集]もう一つあります現在の議論

私の意見では、この質問に「はい」か「いいえ」で投票することはできません。それはアプリケーションの設計に完全に依存します。

私は、前面にアプリケーションサーバーがある 3 層環境での SP の使用には全面的に反対します。この種の環境では、ビジネスロジックを実行するためにアプリケーションサーバーが存在します。さらに SP を使用すると、ビジネスロジックの実装がシステム全体に分散され始め、誰が何を担当するかが非常に不明確になります。最終的には、基本的に次のこと以外は何も行わないアプリケーションサーバーが完成します。

(Pseudocode)

Function createOrder(Order yourOrder) 
Begin
  Call SP_createOrder(yourOrder)
End

つまり、最終的には、それぞれ 16 個の CPU を備えたこの非常に優れた 4 サーバークラスター上で中間層を実行することになりますが、実際には何も実行されません。なんてもったいない！

DB またはさらに多くのアプリケーションに直接接続するファット GUI クライアントがある場合は、話は別になります。この状況では、SP は、アプリケーションをデータモデルから切り離し、制御可能なアクセスを提供する、ある種の疑似中間層として機能します。

コード内での利点:

メンテナンスが容易 - クエリを更新するために SQL スクリプトを実行する必要がありません。

別の DB への移植が容易 - 移植するためのプロシージャが不要

実際、あなたはそれを逆に考えていると思います。私見ですが、コード内の SQL は次の理由から維持するのが大変です。

関連するコードブロックで同じことを繰り返すことになります
SQL は多くの IDE で言語としてサポートされていないため、タスクを実行するのはエラーチェックされていない一連の文字列のみです。
データ型、テーブル名、または制約の変更は、データベース全体を新しいデータベースに交換するよりもはるかに一般的です。
クエリが複雑になるにつれて難易度も上がります
インラインクエリをテストするにはプロジェクトを構築する必要があります

ストアドプロシージャはデータベースオブジェクトから呼び出すメソッドと考えてください。ストアドプロシージャは再利用がはるかに簡単で、編集する場所は 1 か所だけであり、DB プロバイダーを変更した場合、変更はコードではなくストアドプロシージャ内で行われます。。

とはいえ、Stu が私の前で言ったように、ストアドプロシージャのパフォーマンスの向上は最小限であり、ストアドプロシージャにブレークポイントを (まだ) 置くことはできません。

CON

ストアドプロシージャ内で多くの処理を実行すると、アクションをスケーリングする際に、DB サーバーが柔軟性のない単一点になってしまうことがわかりました。

ただし、SQL サーバーではなくプログラム内で処理を実行すると、 かもしれない コードを実行するサーバーが複数ある場合は、さらに拡張できます。もちろん、これは通常のフェッチまたは更新のみを行うストアドプロシージャには当てはまりませんが、データセットのループなど、より多くの処理を実行するストアドプロシージャには当てはまりません。

長所

価値のあるパフォーマンス (DB ドライバーによるクエリ解析の回避/プランの再作成など)
データ操作は C/C++/C# コードに埋め込まれていないため、確認する低レベルのコードが少なくなります。SQL は冗長性が低く、個別にリストすると見やすくなります。
分離のおかげで、SQL コードをより簡単に見つけて再利用できるようになります。
スキーマが変更されたときに変更するのは簡単です。同じ出力をコードに与えるだけで問題なく動作します。
別のデータベースへの移植が容易になります。
ストアドプロシージャの個々のアクセス許可を一覧表示し、そのレベルでアクセスを制御することもできます。
データ変換コードとは別にデータクエリ/永続化コードをプロファイリングできます。
変更可能な条件をストアドプロシージャに実装でき、顧客サイトでのカスタマイズも簡単です。
スキーマとステートメントをコード内に埋め込んで検索する必要がある場合よりも、いくつかの自動化ツールを使用してスキーマとステートメントを一緒に変換する方が簡単になります。
すべてのデータアクセスコードを 1 つのファイル内に収めると、データアクセスのベストプラクティスを確実に実行することが容易になります。パフォーマンスの悪いテーブルにアクセスするクエリや、より高いレベルのシリアル化を使用するクエリ、またはコード内の * の選択などをチェックできます。。
すべてを 1 つのファイルにリストすると、スキーマの変更/データ操作ロジックの変更を見つけやすくなります。
SQL の編集内容が同じ場所にある場合、編集内容の検索と置換が容易になります。すべてのストアドプロシージャのトランザクション分離ステートメントを変更/追加します。
私と DBA 担当者は、DBA が私の SQL 内容をレビューする必要がある場合、別個の SQL ファイルを用意する方が簡単/便利であると感じています。
最後に、チームの怠惰なメンバーが埋め込み SQL を使用するときにパラメータ化されたクエリを使用しなかったため、SQL インジェクション攻撃について心配する必要はありません。

ストアドプロシージャのパフォーマンス上の利点は、多くの場合無視できるほどです。

ストアドプロシージャのその他の利点:

リバースエンジニアリングを防止します（もちろん暗号化して作成した場合）
データベースアクセスの集中化の改善
データモデルを透過的に変更する機能 (新しいクライアントを展開する必要なし)。複数のプログラムが同じデータモデルにアクセスする場合に特に便利です

私は上に落ちます コード 側。すべてのアプリ (Web とクライアントの両方) で使用されるデータアクセスレイヤーを構築しているため、その観点からは DRY です。テーブルスキーマが正しいことを確認するだけで済むため、データベースのデプロイメントが簡素化されます。ソースコードやデータベースを確認する必要がないため、コードのメンテナンスが簡素化されます。

データモデルとの緊密な結合については、あまり問題はありません。なぜなら、その結合を実際に解除できる場所がわからないからです。アプリケーションとそのデータは本質的に結びついています。

ストアドプロシージャ。

エラーが発生したり、ロジックが少し変更された場合でも、プロジェクトを再コンパイルする必要はありません。さらに、プロジェクト内のクエリをコーディングした 1 つの場所だけでなく、さまざまなソースからのアクセスも可能になります。

ストアドプロシージャを保守するのが難しいとは思いません。ストアドプロシージャをデータベースに直接コーディングするのではなく、最初に別のファイルにコーディングする必要があります。その後、セットアップが必要な DB 上でストアドプロシージャを実行するだけで済みます。

ストアドプロシージャの利点:

コードレビューがより簡単に。

結合が少ないため、テストが容易になります。

より簡単にチューニング。

ネットワークトラフィックの観点からは、一般にパフォーマンスが向上します。カーソルなどがある場合、データベースへの複数回のアクセスがありません。

データへのアクセスをより簡単に保護し、テーブルへの直接アクセスを削除し、proc を通じてセキュリティを強化することができます。これにより、テーブルを更新するコードを比較的迅速に見つけることもできます。

他のサービス (レポートサービスなど) が関与している場合は、すべてのロジックをコード内に格納するよりもストアドプロシージャに格納し、それを複製する方が簡単な場合があります。

短所:

開発者にとって管理が難しくなります:スクリプトのバージョン管理:全員が独自のデータベースを持っていますか?バージョン管理システムはデータベースおよび IDE と統合されていますか?

状況によっては、コード内で動的に作成された SQL の方がストアドプロシージャよりもパフォーマンスが向上することがあります。非常に柔軟である必要があるため、数十のパラメーターを使用して非常に複雑になるストアドプロシージャ (sp_customersearch としましょう) を作成した場合は、実行時にコードではるかに単純な SQL ステートメントを生成できる可能性があります。

これは一部の処理を SQL から Web サーバーに移動するだけだと主張する人もいますが、一般的にはそれは良いことです。

この手法のもう 1 つの優れた点は、SQL プロファイラーで調べている場合、生成したクエリを確認して、20 個のパラメーターを含むストアドプロシージャ呼び出しを確認するよりもはるかに簡単にデバッグできることです。

私はストアドプロシージャが好きですが、アプリケーションにダウンタイムを発生させずにストアドプロシージャを使用してアプリケーションに変更を加えることができたことが何度あったかわかりません。

Transact SQL の大ファンなので、大規模なクエリのチューニングが私にとって非常に役立つことがわかりました。約 6 年間、インライン SQL をまったく書いていません。

sproc に関する 2 つのプロポイントをリストします。

パフォーマンスはそうではありません。SQL 2000 以降では、クエリプランの最適化は非常に優れており、キャッシュされます。Oracleなども同様のことをしていると思います。もうパフォーマンスのために sproc を使う必要はないと思います。

安全？なぜ sproc のほうが安全なのでしょうか?かなり安全でないデータベースを使用している場合を除き、すべてのアクセスは DBA から、またはアプリケーション経由で行われます。常にすべてのクエリをパラメータ化します。ユーザー入力から何かをインライン化しないでください。大丈夫です。

いずれにせよ、それがパフォーマンスのベストプラクティスです。

私が今新しいプロジェクトに取り組むなら間違いなく Linq です。これを参照してください同様の投稿.

@キース

安全？なぜ sproc のほうが安全なのでしょうか?

Komradekatz が提案しているように、(DB に接続するユーザー名とパスワードの組み合わせの) テーブルへのアクセスを禁止し、SP アクセスのみを許可することができます。そうすれば、誰かがデータベースのユーザー名とパスワードを取得した場合、SP を実行できますが、テーブルや DB の他の部分にはアクセスできません。

(もちろん、sproc を実行すると必要なデータがすべて得られる可能性がありますが、それは利用可能な sproc によって異なります。テーブルへのアクセスを許可すると、すべてにアクセスできるようになります。)

こう考えてみてください

4つのWebServersと同じSQLコードを使用するWindowsアプリの束があります。SQLコードに小さな問題があることに気付いたので、むしろ......Procを1か所で変更するか、すべてのWebServersにコードをプッシュし、すべてのWindowsボックスにすべてのデスクトップアプリ（ClickOnceが役立つ場合）を再インストールします

ストアドプロシージャの方が好きです

また、PROCに対してパフォーマンステストを行う方が簡単です。それをクエリアナライザーセット統計IO/時間に設定したshowplan_text onとvoilaの時間に配置することも簡単です

何が呼び出されているかを正確に確認するためにプロファイラーを実行する必要はありません

私の2セントだけ

私は、(インラインやアドホックではなく、ORM を使用して) コード内にそれらを保持することを好みます。これにより、.sql ファイルの保存に対処することなくソース管理でカバーできるようになります。

また、ストアドプロシージャは本質的に安全性が高いわけではありません。sproc を使用すると、インラインと同じくらい簡単に不適切なクエリを作成できます。パラメーター化されたインラインクエリは、sproc と同じくらい安全です。

アプリのコードを最適な機能として使用します。ロジックを処理します。
データベースを最大限に活用するために使用します。データを保存します。

ストアドプロシージャをデバッグすることもできますが、コード内のロジックをデバッグおよび保守する方が簡単です。通常、データベースモデルを変更するたびにコードの再コンパイルは終了します。

また、オプションの検索パラメーターを使用したストアドプロシージャは、使用可能なすべてのパラメーターを事前に指定する必要があるため、非常に非効率的であり、検索でパラメーターが何回繰り返されるか予測できないため、複雑な検索ができない場合があります。

セキュリティに関しては、ストアドプロシージャの方がはるかに安全です。いずれにせよ、すべてのアクセスはアプリケーションを介して行われるだろうと主張する人もいます。多くの人が忘れているのは、セキュリティ侵害のほとんどは企業内部から発生しているということです。あなたのアプリケーションの「隠された」ユーザー名とパスワードを知っている開発者が何人いるか考えてみてください。

また、MatthieuF 氏が指摘したように、アプリケーション (デスクトップまたは Web サーバー上にあるかどうか) とデータベースサーバー間のラウンドトリップが減少するため、パフォーマンスが大幅に向上する可能性があります。

私の経験では、ストアドプロシージャによるデータモデルの抽象化により、保守性も大幅に向上します。過去に多くのデータベースを保守しなければならなかった人として、必要なモデル変更に直面したときに、ストアドプロシージャを 1 つまたは 2 つ変更するだけで、その変更がすべての外部アプリケーションに対して完全に透過的に行われることは非常に安心です。多くの場合、データベースを指しているのはアプリケーションだけではありません。他のアプリケーションやレポートソリューションなどが存在します。そのため、テーブルへのオープンアクセスでは、影響を受けるすべてのポイントを追跡するのが面倒になる可能性があります。

また、SQL プログラミングを専門家の手に委ね、SP がコードの分離とテスト/最適化を容易にするために、プラスの列にチェックを入れます。

私が感じる 1 つの欠点は、多くの言語ではテーブルパラメーターの受け渡しが許可されていないため、不明な数値のデータ値を渡すのが煩わしい場合があり、一部の言語では依然として単一のストアドプロシージャから複数の結果セットを取得できないことです (ただし、後者は、その点で SP をインライン SQL よりも悪くするものではありません)。

私が参加したセキュリティに関する Microsoft TechEd セッションからの提案の 1 つは、すべての呼び出しをストアドプロシージャ経由で行い、テーブルへの直接アクセスを拒否するというものでした。このアプローチは、追加のセキュリティを提供するものとして請求されました。セキュリティのためだけに価値があるかどうかはわかりませんが、すでにストアドプロシージャを使用している場合は、害はありません。

ストアドプロシージャに配置すると、保守が確実に簡単になります。将来変更される可能性がある難しいロジックが含まれている場合は、複数のクライアントが接続しているときにそれをデータベースに保存することをお勧めします。たとえば、私は現在、エンドユーザー Web インターフェイスと管理用デスクトップアプリケーションを備えたアプリケーションに取り組んでいます。どちらもデータベースを共有しており (当然ですが)、データベース上にできる限り多くのロジックを保持しようとしています。これはその完璧な例です DRY原理.

ストアドプロシージャで不正行為をしたり動的 SQL を使用したりしないことを前提として、私はストアドプロシージャの側にしっかりと立っています。まず、ストアドプロシージャを使用すると、dba はテーブルレベルではなくストアドプロシージャレベルで権限を設定できるようになります。これは、SQL インジェクション攻撃に対処するためだけでなく、内部関係者がデータベースに直接アクセスして変更を加えることを防ぐためにも重要です。これは詐欺を防ぐための方法です。個人情報 (SSN、クレジットカード番号など) を含むデータベースや、何らかの形で金融取引を作成するデータベースには、保存された手順以外にはアクセスしてはなりません。他の方法を使用すると、社内の個人が偽の金融取引を作成したり、なりすましに使用できるデータを盗んだりできるよう、データベースが広く公開されたままになることになります。

ストアドプロシージャは、アプリから送信される SQL よりも保守とパフォーマンスの調整がはるかに簡単です。また、データベース構造の変更がデータのアクセス方法にどのような影響を与えるかを dba が確認できるようになります。私はデータベースへの動的アクセスを許可する優秀なデータベース管理者に会ったことがありません。

私が現在働いている職場では、Oracle DB でストアドプロシージャを使用しています。Subversion も使用しています。すべてのストアドプロシージャは .pkb および .pks ファイルとして作成され、Subversion に保存されます。以前にインライン SQL を実行したことがありますが、面倒でした。私はここでのやり方の方がずっと好きです。新しいストアドプロシージャの作成とテストは、コード内で行うよりもはるかに簡単です。

あります

小さい丸太

言及されていないストアドプロシージャのもう 1 つの小さな長所:SQL トラフィックに関しては、sp ベースのデータアクセスによって生成される 多くの 交通量が少なくなります。これは、分析やプロファイリングのためにトラフィックを監視する場合に重要になります。ログははるかに小さくなり、読みやすくなります。

私はストアドプロシージャの大ファンではありませんが、次のような条件でストアドプロシージャを使用しています。

クエリが非常に大きい場合は、コードから送信するのではなく、ストアドプロシージャとしてデータベースに保存することをお勧めします。そうすれば、アプリケーションサーバーからデータベースに大量の文字列文字を送信する代わりに、 "EXEC SPNAME" コマンドが送信されます。

データベースサーバーと Web サーバーが同じネットワーク上にない場合 (インターネット通信など)、これは過剰です。そうでないとしても、ストレスが多すぎると帯域幅が多く無駄になります。

しかしまあ、彼らは管理するのがとてもひどいです。私はできる限りそれらを避けます。

SQL ストアドプロシージャはクエリのパフォーマンスを向上させません

ストアドプロシージャを使用すると、コード内で SQL を構築するよりも明らかに利点がいくつかあります。

コードの実装と SQL は互いに独立します。
コードが読みやすくなります。
一度書いたら何度でも使えます。
一度変更する
データベースに関する内部詳細をプログラマに伝える必要はありません。など、など

ストアドプロシージャは、 もっと 次の理由により保守可能です。

SQL を変更したいときに C# アプリを再コンパイルする必要はありません
結局 SQL コードを再利用することになります。

コードの繰り返しは、最悪保守可能なアプリケーションを構築しようとしているときにできることです。

複数の場所で修正が必要な論理エラーが見つかった場合はどうなりますか?コードをコピーして貼り付けた最後の場所を変更することを忘れがちです。

私の意見では、パフォーマンスとセキュリティの向上はさらにプラスです。 安全でない/非効率な SQL ストアドプロシージャを作成することもできます。

別の DB への移植が容易 - 移植するためのプロシージャが不要

すべてのストアドプロシージャをスクリプトアウトして別の DB に作成するのは、それほど難しいことではありません。実際 - それは より簡単に 主キーや外部キーを気にする必要がないため、テーブルをエクスポートするよりも便利です。

@Terrapin - sproc もインジェクション攻撃に対して同様に脆弱です。私が言ったように：

常にすべてのクエリをパラメータ化します。ユーザー入力から何かをインライン化しないでください。大丈夫です。

これは、sproc と動的 SQL にも当てはまります。

アプリを再コンパイルしないことが利点であるかどうかはわかりません。つまり、いずれにせよ、再度稼働する前に、そのコード (アプリケーションと DB の両方) に対して単体テストを実行しているということです。

@Guy - はい、その通りです。sprocを使用すると、アプリケーションユーザーが基になるアクションではなくsprocのみを実行できるように制御できます。

私の質問は次のようになります。更新/挿入などの制限された権限を持つ接続とユーザーを使用して、すべてがアプリ経由でアクセスする場合、この追加レベルによりセキュリティまたは追加の管理が追加されますか?

私の意見はほとんど後者です。アプリケーションが書き換えられるほど侵害されている場合、他にも利用できる攻撃は数多くあります。

コードを動的にインライン化する場合、これらの sproc に対して SQL インジェクションを実行できるため、すべてのユーザー入力を常にパラメータ化する必要があるという黄金律が引き続き適用されます。

これまで言及されていないこと:データベースを最もよく知っている人が、必ずしもアプリケーションコードを作成する人であるとは限りません。ストアドプロシージャは、データベース担当者に、SQL についてあまり学びたくないプログラマと対話する方法を提供します。大規模なデータベース、特にレガシーなデータベースは完全に理解するのが簡単ではないため、プログラマは必要なものを提供するシンプルなインターフェイスを好む場合があります。それを実現するために 17 のテーブルを結合する方法を DBA に考えさせてください。

そうは言っても、ストアドプロシージャの作成に使用される言語 (PL/SQL は悪名高い例です) は非常に残酷です。これらは通常、今日人気の命令型言語、OOP、または関数型言語に見られる優れた機能をまったく提供しません。COBOL を考えてみましょう。

したがって、ビジネスロジックを含むストアドプロシージャではなく、リレーショナルの詳細を抽象化するだけのストアドプロシージャを使用するようにしてください。

私は通常、OO コードを書きます。おそらく皆さんもそうだと思います。この文脈では、SQL クエリを含むすべてのビジネスロジックがクラス定義に属していることは明らかだと思います。一部がオブジェクトモデルに存在し、一部がデータベースに存在するようにロジックを分割することは、ビジネスロジックをユーザーインターフェイスに組み込むことと何ら変わりません。

ストアドプロシージャのセキュリティ上の利点については、これまでの回答で多くのことが述べられてきました。これらは、次の 2 つの大きなカテゴリに分類されます。

1) データへの直接アクセスを制限します。これは場合によっては間違いなく重要であり、これに遭遇した場合、ストアドプロシージャがほぼ唯一の選択肢になります。ただし、私の経験では、そのようなケースは一般的ではなく例外です。

2) SQL インジェクション/パラメータ化されたクエリ。この反対は真っ赤なニシンです。インライン SQL (動的に生成されたインライン SQL であっても) は、ストアドプロシージャと同様に完全にパラメータ化でき、最新の言語でも同様に簡単に実行できます。ここではどちらにしてもメリットはありません。(「怠惰な開発者はパラメータをわざわざ使用しないかもしれない」という意見は有効な反論ではありません。パラメーターを使用するのではなく、ユーザーデータを SQL に連結することを好む開発者がチームにいる場合は、他の開発者と同様に、まず彼らを教育し、それがうまくいかない場合は解雇します。悪い、明らかに有害な習慣。）

私は SPROC よりもコードを強く支持しています。一番の理由はコードを緊密に結合した状態に保つことであり、次に近い理由は、コードを取り込むための多くのカスタムユーティリティを必要としないソース管理の容易さです。

DAL に非常に複雑な SQL ステートメントがある場合、通常、それらをリソースファイルとして組み込み、必要に応じて更新します (これは別個のアセンブリにすることもでき、データベースごとにスワップアウトするなど)。

これにより、更新のために外部アプリケーションを実行することを「忘れる」ことなく、コードと SQL 呼び出しが同じバージョン管理に保存されます。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow

SQL をストアド プロシージャとコードに保持することの長所と短所は何ですか [終了]

さらに短所:

SQL をストアドプロシージャとコードに保持することの長所と短所は何ですか [終了]