コードをより保守しやすくする (つまり、コードを再コンパイルせずにビジネス ルールを簡単に変更できるようにする) 目的でストアド プロシージャにコードを配置することに賛成または反対する理由は何ですか?
他のすべてが等しい場合、ストアド プロシージャをメンテナンスにとってより良い/より悪いものにしているのは何ですか?
3989 次
19 に答える
22
ストアドプロシージャは、いくつかの理由から悪い習慣です。
最も重要なものの1つは、関心の分離です。ストアドプロシージャを使用すると、ビジネスロジックは、それが属するサービスレイヤーではなく、データレイヤーにあります。この結果の1つは、ビジネスロジックを実装するための1つの言語と1つの言語のみが存在することです。新しいテクノロジーが登場すると、適切な移行パスがなくなります。
ストアドプロシージャを回避するもう1つの確かな理由は、ストアドプロシージャがユーザーとDBベンダーの間に強い絆を生み出すことです。別のDBベンダーに変更することは非常に困難ですが、サービスレイヤーにビジネスロジックを含めると、DBを非常に簡単に交換できます。したがって、ストアドプロシージャは、DBベンダーに大きなメリットをもたらしますが、それほど多くのメリットはありません。
次に、スケーラビリティ。中間層でサービスを作成し、それらをクラスター全体に分散させるのは非常に簡単です。ストアドプロシージャを使用してこれをどのように実行しますか？たとえば、8台のマシン間でさえ、ストアドプロシージャをクラスター化することは非常に難しいと思います。
次に、他のシステムとの統合。システムがデータベースからデータをプルし、ストアドプロシージャや他のシステムからの他のデータに依存している場合、そのロジックはほぼ確実にサービスレイヤーに存在する必要があります。ビジネスロジックの一部がサービスレイヤーにあり、一部がビジネスレイヤーにある場合は、メンテナンスの手間がかかります。
于 2009-02-27T01:23:04.993 に答える
11
それはおそらくあなたのシステムに依存します。私たちにとって、Stored Proc はほぼ独占的に使用されています。Web サイトは 1 つしかないため、ストアド プロシージャに SQL ステートメントを配置することで、DBA がクエリを調整し、問題を引き起こすパフォーマンスを再現することが非常に簡単になります。
于 2009-02-27T00:37:30.127 に答える
11
代替案を考えて...
- システムにクエリをハードコーディングするには
- ユーザー入力に基づいてクエリ文字列を作成するには
- ビジネス エンティティとデータベースの命名規則に基づいて (ORM、LINQ、CodeDom などを介して) コードで動的にクエリを生成するには
- 等...
次に、要件と環境を検討します...
開発者はデータベース管理ツールに精通していますか? それとも、フェンスの db 側を処理するデータベース プログラマーと管理者が増えていますか?
データベーススキーマを頻繁に変更する必要がありますか?
セキュリティはどうですか？データベース ユーザー レベルに至るまでセキュリティが必要ですか? コードまたはデータベースでセキュリティを管理する方が簡単ですか?
ORM を使用すると、開発者は自分で DAL を作成する必要がなくなり、生産性が向上しますか? または、ORM では提供できなかったカスタムの方法で DAL に追加したい追加の複雑さがありますか?
等...
proc の保守が容易かどうかについては、ユーザーが作業したシステムや環境が自分のものとは大きく異なるため、人々はさまざまな意見を持っています。それらが維持しやすいかどうかを考えるのではなく、おそらくあなたがすべきことは、それらがあなたのニーズに合っているかどうかを理解することです. それは本当に良い質問ですが、投稿を編集して環境についてもう少し説明してください。もう少し的を絞ったアドバイスが得られるかもしれません。
于 2009-02-27T02:02:45.990 に答える
9
ストアド プロシージャには、クエリをアプリケーション内に保持するよりも多くの利点があり、その多くについては既に説明しました。
ストアド プロシージャは、アプリケーションとデータの間の抽象化レイヤーとして機能し、抽象化レイヤーが悪いことはめったにありません。
カスケード データベース操作がある場合は、一定レベルの再利用を実現できます。Delete_Employeeたとえば、プロシージャは、アプリケーションからの単一のデータベース要求で、トランザクションでプロシージャを呼び出し、他Delete_Addressの多くのことを実行できます。
ストアド プロシージャの下にあるビューのレイヤーを使用して、スキーマの変更やクエリ/結合のパフォーマンス チューニングからアプリケーションを分離できます。
ストアド プロシージャ レイヤーは、堅牢なエンタープライズ アーキテクチャとフレームワークの重要な部分です。これらのストアド プロシージャにはビジネス ロジックを含めないでください。もちろん、データを通過させるだけで、操作してはなりません。
これらの利点を実現するための適切な規律は、アプリケーション内のすべての手順で一貫性と同じ粒度を維持することです。私は何百もの手順でアプリケーションに取り組んできました。これらすべてのクエリがコードに含まれていた場合、データ レベルのセキュリティを実装することは、不可能ではないにしても、はるかに困難だったでしょう。ストアド プロシージャは簡単に生成できます。全体的な生産性は、ストアド プロシージャを使用しない場合よりも高いと感じています。そしてもちろん、他のすべてのデータベース オブジェクトの場合と同様に、ストアド プロシージャをソース管理に含めることもできます。
于 2009-02-27T02:28:58.987 に答える
6
ベース ソフトウェアが複数の異なる顧客サイトに展開されている場合、個々の顧客ごとに必要なカスタマイズの多くは、データベース (ビューとストアド プロシージャ) を介して行うことができます。SP は、内部で何が起こっているかを気にせずに、標準データをやり取りできるインターフェースと考えることができます。
もちろん、これは、各インストールのカスタム .dll データ レイヤーなど、他の方法で処理することもできます。
ただし、場合によっては、.dll の代わりに SP でカスタマイズすることで、より迅速なカスタマイズが可能になり、DBA またはデータの専門家が引き継ぐことができ、プログラマーはコーディングに取りかかることができます。
SP のコードは、コンパイルされたコードよりも多くの人 (この場合は顧客) が利用できることに注意してください。これは、状況に応じて、良い場合も悪い場合もあります。
一部の企業では、ソフトウェアを再インストールするよりも、ストアド プロシージャを変更する方が政治的に簡単です (これは、誰がより厳しいルールを持っているか、開発者とプロジェクト マネージャー、DBA、または IT/ヘルプ デスクに依存します)。
于 2009-02-27T00:49:01.190 に答える
4
私の経験では、ソース管理は、アプリケーションコードの場合と同じように、データベースを維持するために熱心に使用されることはめったにありません。確かに、これはおそらく常にそうであるとは限りませんが、15年間私はそれを見たことがありません。つまり、開発者が開発に変更を加える可能性が高く、データベースに保存されたライブのプロシージャは、簡単すぎるためにメンテナンスのしやすさを真剣に考えずに禁止されています。
于 2009-02-27T01:31:34.553 に答える
3
ストアド プロシージャに反対しているわけではありませんが、アプリケーションの更新とは別に更新する必要があるため、保守が難しいことをお勧めします (SQL サーバーに格納する必要があります)。
于 2009-02-27T00:36:45.887 に答える
2
同様に、これはその場で変更するのは悪い習慣です。覚えていますか?
真剣に、ストアド プロシージャでコードを作成すると、SQL とのやり取りが確実に高速になります。
しかし、あなたの変更は source-control から遠すぎます。（ソース管理のために、私が知っているように、エクスポートする必要があります）
于 2009-02-27T00:50:24.807 に答える
2
私の経験では、主な欠点は、私が一緒に働いた開発者のほとんどが SQL に慣れていないことだと思います (最初に SQL を書き、デバッグします)。チームが多くの SQL を維持できるようにします。
複数のプラットフォーム (たとえば、Windows と Web アプリの両方) を持っている場合、または古いアプリを新しいテクノロジに移植する場合、データベース プロシージャを再利用できる可能性があるという大きな利点があります。
私が扱っているアプリケーションには、ストアド プロシージャに多くのビジネス機能があり、おそらく修正するバグの半分は SQL コードにあります。重大な場合は、ストアド プロシージャを置き換えることですぐに修正できます。次のリリースを待たなければならないアプリケーション コード。(逆に言えば、SQL コードをそれほど多く書かなければ、そもそもバグが少なかったかもしれません!)
于 2009-02-27T01:20:36.077 に答える
2
ビジネスの世界で 10 年以上、コンサルタントとして CRUD プログラミングを行ってきました。できる限り多くのビジネス ロジックを sprocs とビューに入れていると言えます (そして理にかなっています)。要件は風が吹くたびに変化する傾向があり、データベースにロジックがあると変更が容易になり、(適切なコメント付きで) 自己文書化されます。さらに、sproc を使用すると、セキュリティが向上し、コードを簡単に再利用できます。
FWIW 私はすべての sprocs でソース管理と厳密なテストを使用しています。それ以外のことをするのはただの怠惰です。
于 2009-02-27T02:19:27.900 に答える
2
ストアド プロシージャを使用することをお勧めする理由はいくつかあります。
ビジネス ロジックをデータに近づけることで、データへのクライアント インターフェイスをいくつでも持つことができます。最初は Web サイトのフロント エンドを設計するかもしれませんが、今はレポートが必要です。問題ありません。ビジネス ロジックはデータの隣にあります。API を開き、プロシージャの前に Web サービスを配置します。最もホットな新しい言語を使用したい場合は、どうぞ。ビジネス ロジックはデータの隣にあります。
ストアド プロシージャを使用するもう 1 つの理由は、選択したデータベースとユーザーの間に強い絆が生まれることです。このようにして、料金を支払っている (またはオープン ソースの場合は使用している) DB の組み込み機能を利用できます。また、アプリケーション DB を独立させようとすると、追跡が困難なバグが多数発生する可能性があります。 読み取りの整合性は、各ベンダーのデータベースで異なる方法で機能します。
データベースに組み込まれたスケーラビリティ (クラスター、RAC - ただし、実装されています) を利用できます。自分で書く必要はありません。
バインド変数を使用しないコードを記述するのは困難です (それに関する詳細情報が必要な場合は、Google のソフト パースとハード パースを比較してください)。
バージョン管理 - 私が常にストアド プロシージャのバージョン管理を使用してきた会社。通常、何らかのエディタでストアド プロシージャを記述します。現在、ほとんどのエディターには、少なくとも 1 つの主要なバージョン管理システムのサポートが組み込まれています。
外部コードは、ネットワークを介してデータをプルし、それを操作する必要があります。
最後に、すべての手続き型言語が同じように作成されるわけではありません。MySQL は、ストアド プロシージャを使用する機能をリリースしたばかりで、独自の言語を含め、使用できる多くの言語を提供します。彼らがOracleやSQl Serverに対抗できるとは思えません。私は Oracle 以外の専門家ではないので、誰が一番優れているかについては触れません。Oracle の PL/SQL には、DB カーネルで最適化された多くの機能があります。MS SQLも他の人たちと同じようにそれを行うと確信しています。
これが役に立てば幸いです（そして理にかなっています-長い一日）。
于 2009-02-27T02:26:12.363 に答える
1
私が取り組んでいるプロジェクトでは、SQL プロシージャを変更するだけでほとんどのメンテナンスを実行できます。はい、私の場合、ストアプロシージャはより維持しやすく、コードからSQLステートメントを実行するよりも優れたパフォーマンスを発揮します。
于 2009-02-27T00:42:56.323 に答える
1
ストアド プロシージャにはビジネス ロジックが存在しないため、システムを保守できなくなると主張する人もいます。これらの議論は主に、すべてのビジネス ロジックをアプリケーション層内の特定の領域に格納しようとする DDD および N 層の観点から来ていることを指摘しておきます。これは価値のある目標ですが、考慮に値する他の視点もあります。SP は、ビジネス ロジックを格納するだけではありません。
ちなみに、Oracle の世界では、DB 上の PL/SQL コードにすべてのビジネス ロジックを含めることがベスト プラクティスであると考えられており、リレーショナル データベースについてある程度は知っています。
SP の次の用途を検討してください。
パフォーマンス。多くの場合、SP で複数の SQL ステートメントを実行すると便利です。これにより、アプリケーションが DB への複数回のラウンド トリップを回避できるため、パフォーマンスが大幅に向上する場合があります。
変更管理。SP は、バージョン管理と展開プロセスに関する規律がある限り、保守と変更が簡単です。
SP は稼働中の本番システムに停止することなくリリースできます。これは、24 時間年中無休の運用において大きな利点となります。もちろん、リリース プロセスを厳密に管理する必要があります。
抽象化のレイヤー。アプリとデータベースのやり取りがすべて SP を介して行われる場合、SP はアプリケーションから DB スキーマの詳細を抽象化できます。これは非常に強力な概念です。多くの場合、DB の寿命はアプリよりも長く続くことを考慮してください。アプリは最新のテクノロジとアーキテクチャ パターンを使用して頻繁に更新され、更新されますが、貴重なデータは同じ古いリレーショナル DB に永遠に残ります。多くの場合、これが本来の意図ではなかったとしても、複数のアプリが同じ DB で開発されます。これらのシナリオの SP は、アプリと DB の間で厳密に定義された API を提供するために使用されます。この API は、複数のアプリや同じアプリの複数のバージョンとの一貫した対話を確保するために慎重に制御できます。
この db スキーマとアプリの間の懸念事項の分離により、アプリケーション プログラマーは自由に自分のベストを尽くすことができますが、DBA は、アプリを壊すことなく時間をかけてスキーマを改善する自由な手が残されています。
どのようなアーキテクチャ パターンを採用しても、SP は重要な役割を果たすことができます。どんなデザインも除外せず、他のツールと同じように、意味のある場所で使用してください。
于 2010-01-20T02:08:20.757 に答える
1
一般に、その議論は、コンパイルされたコードが通過するバージョン管理やテストなどを通過するのではなく、ストアド プロシージャにアドホックな変更を加えているために行われます。
私はそれに対して即座にひざまずく反応はありませんが (ここにいるほとんどの人がそうするのとは異なり)、DLL のコンパイルと展開は、そのようなカウボーイ環境ではそれほど難しくありません。または、オンデマンドでコンパイルされる生の .cs ファイルを保持できる CS-Script などを使用することもできます。
ほとんどのコードは簡単に実行できるのに対し、ストアド プロシージャのバージョン管理とテストは難しいといつも感じています。また、ほとんどの RDBMS 手続き型言語はかなり原始的であるため、現代の言語が提供する表現力や抽象化は得られません。
もちろん、バージョン管理は良いことです。そして、ほとんどの場所で、開発者と本番の間のいくつかのプロセス チェックも同様です。;)
于 2009-02-27T00:58:17.550 に答える
0
バージョン管理についてもう 1 つ説明します。私の最後の仕事で、毎日実行されるサードパーティのパッケージを追加し、前回のバックアップから変更された場合は、各オブジェクトの DDL またはコードのコピーを保存しました。それ自体はストアド プロシージャであるため、実行したい方法で手動またはトリガーによって実行できました。それ自体がバージョン管理システムです。
これはかなりいいツールで、たったの 200 ドルでした。変更点を表示するための差分ツールも付属しています。
于 2009-02-27T02:37:50.383 に答える
0
コードベースのビジネス ロジック用に sprocs の使用から生成された DAL に切り替えたのには、いくつかの理由があります。
- データベースに依存しない - インライン SQL または生成 DAL (どちらも ANSI 準拠) を使用することで、Oracle から Postgres、SQL Server などに簡単に切り替えることができます。
- 強制的なソース コード管理 (どちらの場合でも利用できることは認めますが、私たちにとっては非常に役立ちました)
- いずれにせよ、データベースよりもはるかに頻繁に GUI をアップグレードしたため、アップグレードの複雑さが軽減されました。
- 開発者がクライアントの問題をデバッグしやすくなる
于 2009-02-27T03:35:23.240 に答える
0
それは、ストアド プロシージャがどれだけ適切に記述されているかによって異なりますね。T-SQL と PL-SQL は、実践者がある程度の考慮と注意を払ってコーディングしていない場合、C# や COBOL と同じくらい厄介で保守が困難になる可能性があります。
私が取り組んだ最近の拡張機能の 1 つで、意図的に機能をストアド プロシージャに配置しました。主な理由は、機能をより簡単に参照できるようにするためであり、維持することはほとんどありません (ストアド プロシージャは DB レベルとクライアント レベルから呼び出すことができます) ; ロジックを別のレイヤーに配置した場合、それは当てはまりません)。PL-SQL をかなりモジュール化するという良い仕事をしたと思っていましたが、TOAD がそれを分析したところ、4 つのセクションのうち 3 つが良い点を獲得し、最後のセクションは循環的複雑度が高いために打たれました。へー、私はちょうど私自身の主張を証明したと思います!
于 2009-02-27T03:42:49.120 に答える
-1
私はストアド プロシージャを使用しないほうが好きです。なぜなら、比較的データベースにとらわれないでいたいからです。より優れたリレーショナル データベースが登場した場合は、それに移行するオプションが欲しいです。ストアド プロシージャはあなたを閉じ込めます。
于 2009-02-27T01:53:02.053 に答える
-1
ストアド プロシージャの 2 つの利点
これに影響を与える要因の 1 つは、アプリを再デプロイすることなくスキーマの変更を行うことができるため、クライアントの数だと思います。たとえば、DBA として、SQL のチューニングやバグの解決などを行う場合、X クライアントが SQL ステートメントを変更するよりも、1 つの Stored Proc にアクセスする方がはるかに簡単だと思います。アプリを複数のワークステーションに。
適切に実行すると、アプリケーションが使用するスキーマがデータ ストレージ スキーマと異なる可能性があることも意味します。たとえば、データ スキーマを高度に正規化し、アプリケーションが使用する一連のビューとストアド プロシージャを提供したいと考えています。アプリ スキーマは、アプリ コードの変更に合わせて変更され、データ スキーマとは無関係です。これは、マルチアプリケーション システム (たとえば、同じデータを使用する 1 つの読み取り/書き込みアプリと Web サイト アプリ) の真の利点です。
ストアド プロシージャの 1 つの欠点
多くの場合、ストアド プロシージャの作成に使用されるツール セットと言語が異なります。これは、トレーニングやスキル開発などを必要とする理解の妨げになる可能性があります。
于 2009-02-27T01:05:17.330 に答える