sql - ストアドプロシージャが多すぎませんか？

Question

ストアドプロシージャが多すぎるということはありますか？

私はあなたが持つことができる数に制限がないことを知っていますが、これは数百、数千を作成しないパフォーマンスまたはアーキテクチャ上の理由ですか？

score 7 · Accepted Answer

私にとって、数百または数千のストアプロシージャの最大の制限は保守性です。これはパフォーマンスへの直接的な影響ではありませんが、考慮に入れる必要があります。これはアーキテクチャの観点から、アプリケーションの初期開発だけでなく、将来の変更と保守についても計画する必要があります。

つまり、アプリケーションが必要とする数だけ設計/作成する必要があります。ただし、Hibernate、NHibernate、.NET LINQ を使用する場合は、できるだけ多くのストアプロシージャロジックをコードに保持し、速度が重要な場合にのみデータベースに配置します。

score 7 · Accepted Answer

7

はい、できます。

ゼロよりも多い場合は、多すぎます

于 2008-09-25T20:45:53.437 に答える

score 4 · Accepted Answer

ここでのより深い質問は、そのすべてのコードを他にどこに置くべきかということだと思います。ビューを使用すると、標準 SQL を介してデータに簡単にアクセスできます。より強力なアプリケーション言語とライブラリを使用して SQL を生成できます。ストアドプロシージャは、データの性質をあいまいにし、抽象化、複雑さ、およびメンテナンスの不要なレイヤーをシステムに導入する傾向があります。

基本的な SQL を生成するオブジェクトリレーショナルマッピングツールの機能を考えると、ストアドプロシージャに過度に依存しているシステムは開発効率が低下します。ORM を使用すると、記述するコードが大幅に減ります。

score 4 · Accepted Answer

私の商用 SQL Server 2005 製品には 200 弱ありますが、新しいレポートでは、今後数日間でさらに 10 ～ 20 増加する可能性があります。

可能な場合は「サブルーチン」sproc を作成して、2 つ以上の sproc に 3 つまたは 4 つの同一のステートメントをまとめていることに気付いたときはいつでも、これらのいくつかのステートメントをサブルーチンに変換する時が来ました。

私はすべてのビジネスロジックをそのまま実行するために sprocs を使用する傾向はありません。単に sprocs が「トランザクション」と見なされることを実行することを好みます。奇妙な挿入または更新自体、何かがいくつかのものを「一度に」更新または挿入する必要があるとすぐに、sprocの時間です。

読みやすさ (およびメンテナンス) を支援するために、単純で大雑把な命名規則があります。

製品のコードネームは「Rachel」なので、

RP_whatever - これらは、データを更新/挿入する一般的な sproc です。
              - または小さな結果セットを返す

RXP_whatever - これらは「関数」として機能するサブルーチン sproc です。
              - またはワーカーを RP_ タイプの procs に

REP_whatever - これらは単に美化されたビューとして機能する sproc です。
              - データを変更せず、潜在的に複雑な結果セットを返します
              - 報告目的など

XX_whatever - これらは内部テスト/開発/メンテナンス sprocs です
              - クライアント アプリケーション (またはローカル データベース管理者) が通常使用しないもの

命名は任意です。これは、SQL Server が使用する sp_ プレフィックスと区別するためです。

データベースに 400 ～ 500 個の sproc があることがわかったら心配になるかもしれませんが、各 sproc がどのような種類のアクティビティを担当しているかを識別するシステムがある限り、数百個あってもまったく問題ありません。高水準プログラミング言語でスキーマの変更を追跡するよりも、数百の sproc (依存関係などを見つけるのに SQL Server ツールが役立つ) でスキーマの変更を追跡したいと考えています。

score 3 · Accepted Answer

データベースに変更を加えるときに、それらすべてを維持する必要があるという事実以外に、ということですか? それが私の大きな理由です。1 つのシナリオしか処理できない数百のシナリオよりも、多くのシナリオを処理できる数のシナリオの方が適しています。

score 3 · Accepted Answer

そのようなことすべてでメンテナンスが問題になることを述べておきます。それらが何であり、どのような目的に役立つかを誰が知っていますか? 何年も後に、それらがレガシーシステムの単なる成果物であり、その目的を思い出すことはできませんが、いじるのが怖い場合はどうなりますか?

主なことは、それが可能かどうかという問題だと思いますが、それを行う必要があります。とにかくそれはただの考えです。

score 3 · Accepted Answer

はい、あなたは多すぎることができます。私は数年前、10,000 procs 程度のシステムに取り組みました。それは正気ではなかった。システムを書いた人々は、プログラミングの方法を本当に知りませんでしたが、構造の悪い proc を修正する方法を知っていたので、ほとんどすべてのアプリケーションロジックを proc に入れました。一部のプロシージャは、数千行にわたって実行されました。混乱を管理することは悪夢でした。

多すぎる (砂の中に特定の線を引くことはできません) ということは、おそらく設計が悪いことを示しています。さらに、他の人が指摘しているように、膨大な数の proc に頼ることなく、粒度の細かいデータベースインターフェイスを実現するためのより良い方法があります。

score 2 · Accepted Answer

特定のことが多すぎるということは、おそらくそれが間違っていることを意味します。設定ファイルが多すぎて、画面上のボタンが多すぎます...

他のRDBMSについて話すことはできませんが、PL / SQLを使用するOracleアプリケーションは、カスケード無効化を防ぎ、コードをより適切に管理するために、プロシージャと関数をパッケージに論理的にバンドルする必要があります。

score 2 · Accepted Answer

私の質問は、何百または何千ものストアドプロシージャについて話しているのに、なぜある種のミドルウェアプラットフォームを使用しないのかということです。

昔ながらの私と呼んでくださいが、データベースはデータを保持するだけで、プログラムがビジネスロジックの決定を行うものでなければならないと思いました。

score 2 · Accepted Answer

Oracle データベースでは、パッケージを使用して、関連する手順をグループ化できます。

それらのいくつかと名前空間が解放されます。

score 2 · Accepted Answer

私には、多くのストアドプロシージャを使用すると、PHP API に相当するものが得られるように思えます。互いに関係のない数千のグローバル関数がすべてグループ化されています。それらを関連付ける唯一の方法は、PHP の mysql_ 関数のように、各関数の前にモジュール名を付ける命名規則を用意することです。これを維持するのは非常に難しく、すべての一貫性を保つのは非常に難しいと思います。ストアドプロシージャは、サーバー上で実際に実行する必要がある場合にうまく機能すると思います。単純な選択クエリのストアドプロシージャ、または結合を使用した選択クエリでさえ、おそらく遠くまで行きます。データベースサーバーで高度なロジックを処理する必要がある場合にのみ、ストアドプロシージャを使用してください。

score 1 · Accepted Answer

いいえ、私が知っていることではありません。ただし、それらには適切な命名規則が必要です。たとえば、usp_で開始することは、多くの人が好むことです（sp_で開始するよりも高速です）。

おそらく、レポートsprocはusp_reporting_であり、bussinessオブジェクトはusp_bussiness_などである必要があります。それらを管理できる限り、それらが多数あることに問題はありません。

それらが大きくなりすぎる場合は、データベースを複数のデータベースに分割することをお勧めします。これはより論理的に意味があり、データベースのサイズなどに役立ちます。

score 1 · Accepted Answer

他の方もおっしゃっていますが、管理面の問題です。しばらくすると、干し草の山からことわざの針を見つけることに変わります。ネーミング基準が不十分な場合はなおさらです...

score 1 · Accepted Answer

ストアドプロシージャが多数ある場合は、1 つのデータベースに縛られていることに気付くでしょう。それらの一部は、簡単に転送できない場合があります。

1 つのデータベースに縛られるのは、良い設計ではありません。

さらに、データベースとビジネスレイヤーにビジネスロジックがある場合、メンテナンスが問題になります。

score 1 · Accepted Answer

私の最初の大きなプロジェクトは、データベースを抽象化するオブジェクトリレーショナルマッパーを使用して開発されたので、オブジェクト指向ですべてを行いました。データアクセスとビジネスロジックはすべて C# コードだったので、バグの管理と修正がより簡単で、特に変更が容易でした。ただし、複雑なことを行うとシステムが遅く感じたため、特に ORM がデータベースで複雑な結合を行う必要がある場合は、それらを回避するか、プロジェクトを再構築する必要がありました。

私は現在、「私たちのアプリケーションはデータベースのフロントエンドに過ぎない」というモットーを持つ別の会社に取り組んでおり、長所と短所があります。すべてのデータ操作がストアドプロシージャで行われるため、非常に高速なアプリケーションがあります。これは主に SQL Server 2005 を使用しています。 C# コードと SQL ストアドプロシージャは、ORM を使用したときとは対照的に、2 回作業するようなものです。SQL でリファクタリングや厳密に型指定されたオブジェクトはありません。Management Studio やその他のツールは非常に役立ちますが、通常はこの方法により多くの時間を費やします。 .

したがって、プロジェクトのニーズに応じて、非常に複雑なビジネスデータを保持するつもりがない場合は、ストアドプロシージャの使用をまったく避けて、開発者の生活を楽にする ORM を使用することもできます。パフォーマンスが心配で、ストアドプロシージャを使用するよりもすべてのリソースを節約する必要がある場合は、もちろん、その量は設計するアーキテクチャによって異なります。たとえば、CRUD 操作用のストアドプロシージャが常にある場合は、1 つ必要になります。挿入用、更新用、削除用、選択用、リスト用の 1 つで、これらは最も一般的な操作であるため、100 個のビジネスオブジェクトがある場合、これらの 4 つを掛けると、最も基本的なものを管理するためだけに 400 個のストアドプロシージャが得られます。そうです、オブジェクトに対する操作が多すぎる可能性があります。

score 1 · Accepted Answer

そうです、ストアドプロシージャが多すぎる可能性があります。

命名規則はこれに非常に役立ちます。たとえば、常にテーブル名と InsUpd または Get を使用する命名規則がある場合、必要なときに適切なストアドプロシージャを見つけるのは非常に簡単です。ある種の標準的な命名規則がない場合、ほとんど同じことを行う 2 つ (またはそれ以上) のプロシージャを簡単に思い付くことができます。

標準化された命名規則がなくても、次のいくつかを簡単に見つけることができます... usp_GetCustomersOrder、CustomerOrderGet_sp、GetOrdersByCustomer_sp、spOrderDetailFetch、GetCustOrderInfo など。

ストアドプロシージャが多数ある場合に発生し始めるもう 1 つのことは、まったく使用されないストアドプロシージャと、ほとんど使用されないストアドプロシージャがあることです。ストアドプロシージャの使用状況を追跡する方法がない場合は、未使用の手順が大量に発生するか、さらに悪いことに、まったく使用されていないと思われる手順を削除してから、それが年に 1 回または四半期に 1 回しか使用されていないことがわかります。:(

ジェフ

score 1 · Accepted Answer

適切な命名規則、最新のドキュメント、およびそれらを整理するのに十分な単体テストがある間はそうではありません。

score 0 · Accepted Answer

spXXX ではなく uspXXX という名前を付けている限り、名前によるルックアップは直接的なものになるため、マイナス面はありません。

score -1 · Accepted Answer

そのすべてのコードをどこかに配置する必要があります。
ストアドプロシージャを使用する場合 (個人的には好みますが、多くの場合は使用しません)、必要なだけ使用することをお勧めします。少なくともすべてのデータベースロジックは 1 か所にあります。欠点は、通常、ストアドプロシージャでいっぱいのバケットにはあまり構造がないことです。

あなたの電話！:)

sql - ストアドプロシージャが多すぎませんか？

19 に答える 19

Related

Reference