web-dev-qa-db-ja.com

ケースステートメントとコード化されたifステートメント

より効率的なのは、SQLのcaseステートメントで処理するか、コードのifステートメントを使用して同じデータを処理することです。私の同僚は、多くのケースステートメントを含む巨大なクエリを持っているので、私は尋ねています。私は彼女に、caseステートメントをコーディングしてDBのストレスを取り除くようにアドバイスしました。私はそれがより効率的であることを発見しました...しかしなぜですか？

sqlasp-classiccase-statement
16
Eric

ここでは尋ねられていない、より基本的な質問があります。これらのCASEステートメントは実際に何をしているのでしょうか？

少しの間パフォーマンスを忘れてください。 CASEがクエリの最終出力を変換するためにのみ使用されており、ASPで同じ機能をifまたはselect caseに置き換えることが実際に可能である場合、それはおそらくデータベースのクエリ/プロシージャが、フォーマットなど、UIが担当する必要のあることを実行しようとしていること。関心の分離の問題は、考えられるパフォーマンスの問題よりも深刻です。

このようなクエリがある場合：

SELECT InvoiceID, InvoiceDate,
    CASE WHEN PaidStatus = 0 THEN 'Unpaid' ELSE 'Paid' END
FROM ...

UI、またはデータからドメインへのマッピングを行うレイヤーは、データベース内のステータスを対応する説明に変換する方法を知っている必要があるため、これはばかげています。このロジックをクエリ自体に含めることは意味がありません。

一方、CASE構造がクエリの重要な部分である場合は、次のようになります。

SELECT
    SUM(CASE WHEN PaidStatus = 0 THEN Amount ELSE 0 END) AS TotalUnpaid,
    SUM(CASE WHEN PaidStatus = 1 THEN Amount ELSE 0 END) AS TotalPaid
FROM ...

この種のロジックをUIに移動しようとさえしないでください。データベースの方がはるかに優れているからです。また、CASEは意味的にクエリの一部であり（ "x"の支払い済みと未払いの合計金額を計算します）、UI関数を引き継ぐことはありません。

最初に、ロジックが何を達成しようとしているのかに基づいて、ロジックが実際にどこに属しているかを心配します。パフォーマンスの懸念は、実際に重大なパフォーマンスに気付いた場合にのみ議論に参加する必要があります問題。

31
Aaronaught

CASEステートメントが推奨される理由は次のとおりです。

  • SQL：これらはANSI規格であり、変更することなく他のデータベースに移植できます。
  • それらは「短絡」をサポートします
6
OMG Ponies

私の経験では、データベースサーバーはアプリケーションサーバーよりもはるかに大きく、通常は30％未満のアイドル状態になっています。データベースにデータを管理させてから、クライアントにresultSetを反復処理させます。データベースに必要なデータのみを返すようにすることをお勧めします（これを事前に判断できる場合）。

2
northpole

データベース内のデータをクエリ（フィルタリングおよびソート）し、プレゼンテーションをプレゼンテーション層に任せる必要があります。これには2つの主な理由があります。

  • データベースは、データをフィルタリングおよびソートするために作成されます
  • 必要に応じて、DBからネットワーク経由で最小限のデータをプルする必要があります
1
Keith Adler

私が読んだように、ここでの基本的な質問は、SQLでCASEがIFよりも優れているかどうかです。答えはあなたの状態の深さにも依存します。ここで良い記事を見つけました。誰かに役立つかもしれません。 http://www.4guysfromrolla.com/webtech/102704-1.shtml

0
Ram Dwivedi