真のルックアップテーブルのメリットとメリット

Question

だから、1つのルックアップテーブルを持つことが最善の方法ではないことを十分に理解しています。パフォーマンスの観点から、それはなぜですか？次の例を考えてみましょう。

都市の学校リストがあります。ある都市には複数の学校があります。 あなたは2つの都市の間にジャンクションテーブルschoolCitiesを持っています。ビジネスのリストを考えてみましょう。各都市に複数の事業が存在する可能性があります。だからあなたはジャンクションテーブルのビジネス街を持っています。本当に質問です。なぜなら、1つの都市テーブルを使用して、学校やビジネスのための接合テーブルを作るのではなく、各テーブルの学校やビジネスに独自の都市テーブルのコピーを持たせるのはなぜでしょうか？

Answer 1

説明しているのは、「真のルックアップテーブル」ではありません。あなたの例のCitiesテーブルは良い正規化のアイデアのように聞こえます。 「1つの真のルックアップテーブルは、」より

CREATE TABLE TheOne (
    LookupType varchar(20) NOT NULL -- City, color, shoe size...? 
    , LookupValue varchar(1000) NOT NULL -- how big does it have to be? 
    , CONSTRAINT pk_TheOne PRIMARY KEY (LookupType, LookupValue) 
) 

ようになると、あなたは価値があるかもしれません：

'City', 'Philadelphia' 
'City', 'St. Petersburg' 
'City', 'Paris' 
'State', 'Pennsylvania' 
'State', 'Florida' 
'Country', 'United States' 
'Country', 'France' 
'Brand', 'Lucky' 
'Brand', 'Diesel' 
'Brand', 'Old Navy' 

のように。悪の権化。

都市表は、おそらく、同じ名前（パリ、リマ、レビットタウンなど）を持つ多くの異なる都市が存在する可能性があるため、都市を州または他の親の地理的領域と関連付けます。

Answer 2

実際、OTLTの設計にはいくつかの利点があります（私は文字通り、今すぐ頭が爆発していると感じています）。

私が実際にうまく動作しているモデルは、このようなものです。

LookupId、LookupTypeId、言語ID、説明（表示データ）

そして、ストアドプロシージャのあなたのparams。 （すべての型を取得するために）型IDだけになります。特定の型のIDを変換するだけであれば、LookupIdを渡すだけです。デフォルトの言語が設定されます（この場合、英語です）。これは、サイトの表示データを多言語形式でスキンするのに最適な方法でした。

実際にはMatch.comを使用し、1日に数百万人のユーザーをサポートしています。文字通りWeb起動時の検索をキャッシュしています。それは非常に効率的なシステムでした。最大の利点は、大規模な表スキーマの追加/変更ではなく、文字通りデータをプロダクションにプッシュできることでした。

小さなドロップダウンデータ（一般的なアプリケーション表示のもの）しか扱っていない限り、パフォーマンス、メンテナンス、追加の容易さという点で大きな利点があります新しいタイプ。

私はそれが人気のない方法論であることを知っています。しかし、適切なシナリオではうまく機能し、使用が制限され、訓練されているとうまくいきます。

ちょうど私の2セントです。私はポイントを控除してもらうか、トピックに人気のないスタンドを取っても何でもよいと確信しています。