ストアドプロシージャの構造化

Question

多くの場合、ビジネスロジックをアプリケーションに書き込むために使用されるストアドプロシージャがあります。これらのprocsには、1000行以上のコードが含まれることがあります。 1000行のアプリケーションコードにメソッド/関数を書くと正しく批判されます。長いprocsを別のprocsに分割しなければならないのでしょうか？クラス内のメソッドはそうでしょうか？確かにコードをより使いやすくするために、これ以上のことはしません。

Answer 1

まず、Natの答えに同意します.T-SQLデバッグ用のツール（デバッガなど）は、他の言語で見つかる機能の近くにはありません。

第2に、ストアドプロシージャ間で値を渡すときにいくつかの潜在的な問題があります。単純なデータ型を渡すのは簡単です。関連するデータ型を渡すことはより複雑になります。テンポラリテーブルを使用すると、XML、区切り文字列、レコードセットなどに追加のコーディングが必要になり、オーバーヘッドが増え、パフォーマンスに影響が出ます。

入力パラメータと出力パラメータを標準のメソッド（標準データ型）で処理できる場合は、ストアドプロシージャを分割することが必要です。入力と出力を渡すために多くのコーディング作業が必要な場合、ストアドプロシージャーは大きく維持されます。

Answer 2

データベースのサービスレイヤーについて考える必要があるように思えます。これにより、多くの手続き型コードのビジネスロジックをより適切な言語に移行できますが、承認されたAPIを通じてデータベースへのアクセスを強制します。

Answer 3

"コード行"は、コードの再利用可能性の尺度ではないと思います。私はあなたがこれらの「長い」手続きをはるかに質的に見る必要があると思います。私は過去にいくつかの長い手順を経ていましたが、コードを短縮しモジュール化できるかどうかは本当に依存していますか？ロジックが実際に他のアプリケーションによって再利用されているのか、それとももっと教科書の欲望ですか？私は、1000行以上のコードがあり、批判されたり、小さな部分に分解される必要がないエンタープライズアプリケーションにたくさんのモジュールがあると確信しています...

1000行以上のコードは正当化されていますか？もちろん違います。私はちょうどあなたが見なければならない唯一の要因ではないことを強調したいと思います。

Answer 4

長いストアドプロシージャは、再利用可能で堅牢な短いコードブロックに分割する必要があります。残念なことに、データベース開発で使用されている言語とツールは、実際にこれを行うことをサポートしていません。

Answer 5

あなたのSPが非常に大きい場合、あなたはこの手順が「多くのことをします」と明確に言えるでしょう。もしそうなら、あなたはこれらのことを別々にするべきです。 この機能をサポートする必要がある場合は、1000行のスパゲッティコードで作業するよりも、そのようなSPを一度簡単にリファクタリングすることができます。