web-dev-qa-db-ja.com

T-SQLまたはプログラムで計算を行う必要がありますか？

一部のデータをログに記録するストアドプロシージャを作成しています。最終的に、データは2つのテーブルになる必要があります。受信データは15個のパラメーターを含むJSON文字列から取得され、データは、作成しているストアドプロシージャを使用してデータベースに記録されます。データを1つのストアドプロシージャに送信し、両方のテーブルに挿入したいと思います。

最初のテーブルは、生データのロギングテーブルです。デバッグとトラブルシューティングに使用されます。

2番目のテーブルは、レポートの生成に使用されます。このテーブルでは、受信データに対していくつかの簡単な数学的計算を行う必要があります。例えば：

DECLARE @Table2Fld3 DECIMAL = @IncomingFld9 - @IncomingFld4;

テーブル2の値を計算するには、これらの計算のうち約8つを行う必要があります。次に、INSERTを実行してデータを保存します。

だから私の質問は、これらの計算をT-SQLで行うことは良い習慣なのでしょうか？または、2つの個別のストアドプロシージャを作成し、コードで計算を行う方がよいでしょうか？

私が目にする1つのトレードオフは、コードですべてを実行する場合、2つのデータベース接続を作成する必要があることです。

[〜＃〜]編集[〜＃〜]

「2データベース接続」のコメントについて詳しく説明します。問題のアプリケーションは、マルチスレッドのサーバー/クライアント通信を確立するWindowsサービスです。ロギングシステムは、サーバー/クライアント通信と非同期です。その既存のシステムを使用して、私が複数のストアドプロシージャを対象とするためには、データベースへの2つの接続を起動するロガーへの2つの呼び出しが必要になります。

c#sql-servertsql
7
jwatts1980

たくさんの理由で（そして全体に入るのではなく）データベースにロジックを（allではなく）たくさん保持することを好む最近のストアドプロシージャが必要な人」の引数）。

ストアドプロシージャでこれを行います。

これらは単純な計算のように見えます。また、sprocでトランザクションを使用して両方のテーブルへの書き込みを管理しますを除きデータベースが不整合になっても問題ありません（書き込みが1つで成功する場合もあります）テーブルではなく、他）。そして、「本物のプログラマは自分のロールバックコードを書く」と言っている人に耳を傾けないでください。 :-)信頼できる唯一のロールバックコードは、データベースエンジン自体内のロールバックコードであり、簡単に使用できます。

データベース外の命令コードでこれらの計算を行い、2つのストアドプロシージャを使用してデータを書き込む場合、stillは、データベーストランザクションの利用を検討する必要があります。データベースが不整合になるのは問題ありません。したがって、（データベースの外でこれを行うと）突然、データベースへのラウンドトリップ呼び出しが最大で1ではなく最大4になります。

  1. TXを開始
  2. テーブル1を作成
  3. テーブル2を書き込む
  4. コミットTX

書き込みが少ない場合は、データベースで行われる実際の作業よりもネットワークラウンドトリップでオーバーヘッドが大きくなる可能性があります。同じ接続を使用して両方のストアドプロシージャを呼び出すことができますが（トランザクションを使用する場合）、ネットワークを介してデータベースサーバーに対して複数の個別の呼び出しを行う必要があります。

最後に、計算のロジックが変更され、データベース外のコードでそれらの計算を実行している場合は、そのコードを変更して再コンパイルし、更新されたプログラムを再デプロイする必要があります。ただし、ストアドプロシージャにこれらの計算がある場合は、アプリケーション全体を再展開（再インストール）する必要なく、その1つのストアドプロシージャを再構築できます。

シッククライアントデスクトップアプリ（指定しなかった）の場合は、これらのすべての点が悪化します。これは、更新されたアプリをすべてのワークステーションに再インストールする必要があり、一部のワークステーションにインストールしているときにワークステーションは他のワークステーションではなく、データベースに対して異なるワークステーションを使用しています。また、ソース管理とビルドプラクティスに応じて、過去にさかのぼってリポジトリをブランチし、データアクセスレイヤーに変更を加えるための主要な操作を検討している可能性があります。メインソース行のDALへのブランチ。

ストアドプロシージャでこれを実行してください。正直なところ、それを行うのに適切な場所だからです。

7
Craig

私はできるだけ多くのロジックoutsideデータベースを保持することを好みます。そのため、計算の方法が変わった場合でも、プログラムのコードを更新するだけで済み、ストアドプロシージャをいじる必要はありません。

これらの計算がどれほど複雑かはわかりませんが、それらがボトルネックになった場合は、いつでも別の場所に移動できます。

8
System Down

データベースエンジンの主な役割は、データを格納し、必要なときにプルすることです。

私たちはビジネスロジック/データを使った操作をプログラムコードに入れるべきです。データベースに依存しないように。単体テストが可能です。パフォーマンスが向上します。ビジネスロジックでは、完全なOOPコンセプトを使用できます。

0
DeveloperArnab

これらの簡単な計算はレポートの一部として行う必要があり、レポートテーブルに格納する必要がないように思えます。これにより、計算を変更できる柔軟性が得られ、レポートテーブルでデータを再作成する必要がなくなります。

0
Jeff Martin