0

私は 8 つのテーブルを持っています。

  1. 従業員
  2. 従業員_件名
  3. 出口
  4. アウトレット_サブジェクト
  5. 科目
  6. 地理
  7. アウトレット_ジオグラフィー
  8. employee_geography

今、私は、さまざまな地域の範囲内で、さまざまな主題に基づいて、販売店と従業員を検索できる必要があります。

私の質問は次のとおりです:良い戦略はありますか?範囲に必要なすべてのデータを挿入した、やや静的なルックアップテーブルを作成するのは良い考えですか?

テーブルは潜在的に +5000 万行に増加しますが、私は言うことができます

SELECT ... FROM lookup WHERE subId = 1 OR subId = 2 OR geoId = 1 geoId = 2...etc etc.

だから私は結合を締め出すことができます。

あいまいですが、これについてのガイダンスが必要です!

4

2 に答える 2

2

その質問には一般的に答えることはできません。一部のコンテキストでは、パフォーマンス上の理由から (特にデータ ウェアハウスの場合)、冗長で非正規化されたデータを保持する必要があります。ただし、冗長性や潜在的な矛盾を軽視してはなりません。

最初にクエリのパフォーマンスを測定し、実行計画を確認することをお勧めします。必要なすべての索引を必ず作成してください。それでもクエリが遅すぎることが判明した場合は、具体化されたビュー (SQL サーバーのインデックス付きビューと呼ばれます。たとえば、ここを参照) の使用を検討してください。マテリアライズドは、提案するテーブルに非常に似ていますが、DBMS によって自動的にデータと同期されます。

于 2013-11-09T22:28:47.070 に答える
1

分析クエリ (システムから数値と統計を引き出す) のデータ ウェアハウス コンテキストでは意味があるかもしれませんが、ユーザーが定期的に更新する oltp システムの場合、大きなルックアップ テーブルは非常に悪い設計であり、維持するのが困難です (大量の不要なデータ: すべてのレコードにすべての列が必要なわけではないなど)、不正なデータなど。

システムにクエリを実行するためだけに結合を除外することは、Sql Server オプティマイザーの作業を中断し、テーブル スキャンにつながる可能性が高くなるため (大きなテーブルでは困難な場合があります)、良い考えとは思えません。

これは、大きなルックアップ テーブルに関する Joe Celkoの興味深い記事です。これは、問題に関連しているように聞こえますが、まったく同じではありませんが、いくつかの洞察を得ることができます。

一般的なアドバイスは次のとおりです。正規化された設計を維持します (特に oltp システムの場合)。

于 2013-11-10T12:03:01.517 に答える