0

私は次のテーブル構造を持っています-

サイト：サイトのマスターテーブル

組織：組織のマスターテーブル

ユーザー：ユーザーのマスターテーブル（各ユーザーはUser.OrgIdを介して一意の組織にリンクします）

OrgSite：「組織固有の」サイトの詳細（OrgId、SiteId、SiteName、SiteCode）を保存します。すべてのサイトではなく、Orgにアクセスできるサイトのみ。

UserSite：ユーザーをアクセス可能なサイト（UserId、SiteId）にリンクします。ユーザーが組織にリンクされると、UserSiteはOrgSiteテーブルのサブセットになります。

ItemSite：アイテムとサイト固有の詳細（ItemID、SiteId、OrgId、...）を格納するテーブル

ここで、「ItemSite」からレコードをフィルター処理して表示する必要があります。そのため、サイトコードも表示する必要があります。したがって、次の2つのオプションが表示されます-

1.ビューを作成します： vw_ItemSite_UserSite_OrgSite（SiteIdのすべてのテーブルに内部結合）-これにより、「OrgSite」テーブルで利用可能なすべての組織固有の詳細（つまり、SiteCodeなど）にアクセスできます。

組織固有のSiteCodeとSiteNameが必要なため、ビューに「OrgSite」を含める必要があることに気付く場合。UserSiteはすでにサイトをフィルタリングしているため、OrgSiteテーブルを「除外」して、不要なINNERJOINを削除できます。

2.上記の注意に基づいて-2番目のオプションはVIEWを作成することです：vw_ItemSite_UserSiteそしてVIEWの'SELECT'ステートメントに次のようなSELECTを埋め込むことができます-

CREATE VIEW vw_ItemSite_UserSite AS
SELECT ItemSite.SiteID,
(SELECT TOP 1 [SiteCode] FROM OrgSite WHERE OrgId = ItemSite.OrgId) AS SiteCode,
...
FROM ItemSite INNER JOIN UserSite ON ItemSite.SiteId = UserSite.SiteId

私の唯一の意図は、埋め込まれたselectステートメントの評価の前にINNERJOINとWHEREが評価されると信じていることです。それで、これは私にいくらかのパフォーマンスを節約しますか？または、vw_ItemSite_UserSite_OrgSiteを使用する方が良いという考えです。

オプション＃1またはオプション＃2？

ありがとうございました。

4

3 に答える 3

2

時期尚早の最適化に注意してください。両方のクエリが同じ結果を返す場合は、理解と保守が容易なクエリを使用してください。クエリ操作（結合、選択、...）がパフォーマンスを最適化する順序で実行されるようにするのはSQLServerのタスクです。そして、通常、SQLServerはその上で非常に優れた仕事をします。

とはいえ、SQL Serverクエリアナライザーが最適なクエリプランを見つけられず、自分で微調整する必要がある場合があります。ただし、これらはまれなケースです。クエリですでにパフォーマンスの問題が発生していない限り（そして、欠落しているインデックスを導入しても修正できない場合）、これは今のところ心配する必要はありません。

于 2009-11-18T14:03:40.567 に答える
1

簡単な回答のアプローチを採用します。いくつかのテストを作成し、それらのパフォーマンスをチェックして、特定の環境で実際に最もパフォーマンスが高いものを確認します。

于 2009-11-18T14:36:54.517 に答える
0

オプション1の方がほぼ確実に高速です。通常、組み込みSELECTはパフォーマンスにとって悪い考えです。

しかし、私たちの言葉を信じないでください。両方をコーディングして試して、クエリプランを確認してください。この場合、おそらく時期尚早の最適化ですが、それを学ぶための優れた単純なテストケースでもあるため、それを行う方法と、それを行うための正しい方法が本当に必要な問題が発生した場合の影響を正しく理解できます。同じクエリを作成するさまざまな方法の間には、オプティマイザーが何もできない大きなパフォーマンスの違いがある場合があるため、一般的なルールを事前に学習しておくと、人生がより幸せになります。

于 2009-11-18T17:22:42.343 に答える