Extract メソッドは、プログラミング言語を作成する際の一般的なリファクタリング パターンです。
ストアド プロシージャでいくつかのリファクタリングを行おうとすると、ストアド プロシージャ (SP)/ユーザー定義関数 (UDF) を記述するときに抽出メソッドを使用することも良い方法であるかどうか疑問に思います。他の SP/UDF を呼び出すことができるからです。 SP/UDF?
パフォーマンスに影響しますか?
前もって感謝します。
質問する
199 次
1 に答える
1
私の意見です（現在、データベースで数年間働いています）：
ストアド プロシージャは、データベース タスクにのみ使用する必要があります。たとえば、データの移行 (現在、データベース構造を変換するプロセスに取り組んでいます)、いくつかの動的クエリ (SQL ステートメントがオンザフライで構築される)、またはテーブルを構築する手順 (たとえば、特定の日付範囲の日付を保持するテーブル)。
他の何のためでもありません！上記の例よりも複雑になるすべてのものについては、アプリケーション層でコーディングすることを検討してください。
また、データベースにできるだけ多くのビジネス ロジックを配置することが賢明であると聞いたことがあるかもしれません。これはデータベースの設計には当てはまりますが、データベースのほとんどすべてをコーディングする必要があるという意味ではありません。データベースはそれが得意ではありません (たとえば、データ変換などについて話します)。PHP などのプログラミング言語や、より高速なプログラミング言語を使用してください。
そのため、ストアド プロシージャを使用したすべてのことについて、余分なプロシージャに何かを入れる必要性を感じたことはありませんでした。たとえば、データベースの再構築 (私の場合は ETL プロセスです (パフォーマンスを向上させるためにデータをスター スキーマに非正規化します)) とは別に、すべてのテーブルのプロシージャを記述し、これらのプロシージャは、テーブルを管理するプロシージャから呼び出されます。全体のプロセス。繰り返しになりますが、プログラミング言語のようなものではありません。
また、抽出メソッド パターンhttp://www.refactoring.com/catalog/extractMethod.html
のこの例を取り上げる
と、データベースにこのようなものがあると、デバッグの悪夢になり、コーディングに多くの時間を費やすことになります。繰り返しになりますが、ストアド プロシージャを使用する必要がある場合は、extract メソッド パターンを適用することが理にかなっている場合ではありません。
于 2013-11-14T12:19:38.910 に答える