sql-server - 計算にストアドプロシージャを使用する

Question

私は現在、クライアントに関する特定の財務情報をMSSQLデータベースに保存するプロジェクトに取り組んでいます。後で、ユーザーはデータベースにクエリを実行して、特定の基準（たとえば、特定のサイズよりも大きいクライアント、特定の地理的位置にあるクライアント）に基づいてクライアントからデータを返し、ベンチマークとして使用するために合計できるようにする必要があります。データベースには、スクリプトを使用して財務ソフトウェアからアクセスします。

現在、データベースのストアドプロシージャを作成しています。私が計画しているのは、使用できるさまざまなタイプの基準に基づいて、いくつかの異なるストアドプロシージャを作成することです。彼らはクライアント番号を返します。

私が持っている実際の質問は、データを取得する方法についてです。クライアントのデータを使用して、いくつかの異なる計算を行う必要があります。クライアント番号に基づいて計算を実行して結果を返すために、さまざまなストアドプロシージャを使用する方がよいでしょうか。それとも、ストアドプロシージャでクライアントに関するすべての情報を返し、スクリプトで計算を実行する方がよいでしょうか。

データベースには多数のクライアントが存在するため、パフォーマンスが問題になる可能性があります。そのため、このメソッドを適度に効率的にする必要があります。

Answer 1

興味深いことに、データウェアハウスの人々はこれを常に行っています。多くの場合、可能な限り単純なSQL（SELECT SUM / COUNT ... GROUP BY ...）を使用し、データベースの外部でレポート作成ツールを使用して作業を行います。

データウェアハウスツールキットのコピーを入手して、これをかなり簡単な方法で実行する方法を確認する必要があると思います。より柔軟で、おそらくよりスケーラブルです。

Answer 2

これの多くは、関連するデータと実行している操作に関係していると思います。私は通常、DBからのリターンのサイズ（グループ化と集計）を減らす計算を行う場合、DBで行う方がはるかに効果的であることに気付きます。ただし、他の計算を開始すると、それほど明確ではありません。

Answer 3

あなたが説明しているようなほとんどの場合、ストアドプロシージャを使用する方が効率的ですが、そうでない場合もあります。最善の答えは、両方の方法を試し、負荷テストを実行して、どちらの方法が最も効率的かを判断することです。

Answer 4

それは本当に操作に依存します。これらをデータベース内の計算列として保持する、ビューまたは SP で事前に計算する (または UDF を使用する)、個別に計算して ETL または要約フェーズ中に格納する、またはクライアントに任せることは十分に可能です。

クライアントが間違いを犯さないように一貫して計算を制御できることがわかっていない限り、クライアントに何もさせないようにします (レポート作成者全員が独立して作業を行うと、災害のレシピになります)。変化する。

Answer 5

SQL Server はリレーショナル データストアです。クライアントに対して同じ計算を行う、計算ごとに 1 つのストアド プロシージャをお勧めします。ID をパラメーターとして渡すだけで、クライアント固有の結果を取得できます。

「多くのクライアントが存在するため、パフォーマンスが問題になる可能性があります」....これは、テーブルの正規化とインデックス作成の方法によって異なります。インデックスが実際に何であるかを完全に理解していない限り、すべての列にインデックスを付けないでください。

編集〜計算も調べてください。一部は、フロント エンド クライアントにオフロードできます。

Answer 6

あなたの質問から、最も効率的な方法は、SP ですべての計算を行い、単一の (?) 結果をスクリプトに返すことだと思われます。

スクリプトで処理を行うことにした場合は、取得するデータを必要なデータだけに制限し、データベースへの往復をできるだけ少なくする必要があります。

Answer 7

計算結果を決定するビジネス ルールが変更される傾向がある場合は、ストアド プロシージャでそのようなコードを作成しないでください。これを行うのに適した場所は、コントローラー (MVC の C) です。ルールはプラグ可能で、簡単に変更できます。

また、スケーラビリティの観点からは、アプリケーション サーバーの複製は、データベース サーバーの複製ほど高価ではありません。

ただし、ストアド プロシージャを使用できないという意味ではありません。レポート生成は、ストアド プロシージャを使用して実行される計算の理想的な候補の 1 つです。

Answer 8

データ ウェアハウスが必要かどうかを検討してください。レポート用に最適化されたデータベースは、データ入力用に最適化されたデータベースとは大きく異なります。

Answer 9

あなたの言うことすべてから、データの保管を検討すべきだと思います。OLTP システムに対して複雑な結合を作成し、追加の計算が必要であることに気付いた場合 (そのように思われます)、データを非正規化し、事前に計算された集計をウェアハウスに保存すると、作業が大幅に簡素化されます。

膨大な数の書籍や製品が大量に出回っていますが、問題領域が分散していて、ソース データが適切に管理されていれば、多くの場合、その作業は些細なことです。

Answer 10

ストアド プロシージャで任意の計算を実行し、データを返すことができます。ストアド プロシージャのような利息計算には、多くの計算が必要です。

他のテーブルデータを使用してデータを計算する必要がある方法。

SPでできるSUM、

Declare @SUMAmount decimal(12,3) 

-- @A、@B なども宣言します

Select @SUMAmount= SUM(ISNULL(@A,0)+ISNULL(@B,0)+ISNULL(@C,0)+ISNULL(@D,0))

Select @SUMAmount= SUM((ISNULL(@A,0)+ISNULL(@B,0))*(ISNULL(@C,0)-ISNULL(@D,0)))

あなたの要件に従って、条件を与えることができます。

ISNULL は、データが NULL かどうかのチェックに使用され、0 を返します。Null 値での計算はできないため、ISNULL 条件を指定することをお勧めします。

Select A,B,SUM(C),D From TableName
Where SUM(C)>0
Group By A,B,D

ここでは、集計関数と非集計関数の両方が存在するため、Group By を使用する必要があります。「SUM(C)>0」のように、条件に従って値を取得できます。Group Byの後にここを使用することもできます。

 Declare @TotalNoofDays  int
 @TotalNoofDays = DATEDIFF(d, fromdate, todate) 

この関数を使用して日数を検索するために使用します。

次のような条件を使用できます。

if @DueAmount >=0
BEGIN
IF @DiscountFlag = 1
BEGIN
SET @DueIntAmount   = 0
END
ELSE
   BEGIN
     SET @DueIntAmount  = ((@DueAmount*(@IntRateOnDue/100))/365)*@NoofDays
   END
  SET @ExcessInterestAmount = 0
END
ELSE
BEGIN
SET @DueIntAmount   = 0
SET @ExcessInterestAmount = ((@DueAmount*(@IntRateOnDeposit/100))/365)*@NoofDays
 END

ストアド プロシージャで実行できる計算と同様です。

レコード数を 1 つずつ計算する場合は、一時テーブル while ループを使用できます。

 Create Proc NewLearningProcedure
 (
   @Name Varchar(50),
   @Date DateTime
 )
 AS
 Begin

Declare @Temp Table
(
   ID int Identity(1,1),
   Name Varchar(50),
   Date DateTime
)

Insert Into @Temp
Select @Name,@Date

Declare @i int
set @i=10

While @i>0
Begin
  Insert Into @Temp
  Select @Name+CAST(@i as varchar(50)),@Date

  Set @i=@i-1
 End


 Select * from @Temp


 End

ストアドプロシージャで何でもできるように。