ルックアップテーブルはどのくらい重要ですか？

PostGreSQLなどのフリーウェア（完全にSQLに準拠していない）に限定されている場合、またはSQL（つまり、SQLに準拠している）や大規模なデータベースについて考えている場合は、答えは少し異なります。

SQL準拠の場合、オープンアーキテクチャ データベースでは、1つのデータベースを使用する多くのアプリがあり、データ、標準、正規化、およびオープンアーキテクチャの要件にアクセスするために（アプリだけでなく）さまざまなレポートツールを使用する多くのユーザーが重要です。

刻々と変化する目的に合わせて「正規化」などの定義を変えようとする人々にもかかわらず、正規化（科学）は変わっていません。

• データ値がある場合 {Open; Closed; etc }データテーブルで繰り返される、つまりデータの重複 、単純な正規化エラー：これらの値が変更された場合、数百万行を更新する必要がある場合がありますが、これは非常に限られた設計です。

  • このような値は、短いCHAR(2)を使用して、参照テーブルまたはルックアップテーブルに正規化する必要があります。 PK：

    O  Open
    C  Closed
    U  [NotKnown]
    

  • データ値 {Open;Closed;etc }は、数百万行に複製されなくなりました。スペースも節約できます。

  • 2つ目のポイントは、Closedの場合、変更のしやすさです。 Expiredに変更されました 繰り返しますが、1つの行を変更する必要があり、それはデータベース全体に反映されます。一方、正規化されていないファイルでは、何百万もの行を変更する必要があります。

  • 新しいデータ値の追加 、例えば。 （H,HalfOpen ）は、1行を挿入するだけです。

• オープンアーキテクチャ 用語では、ルックアップテーブルは通常のテーブルです。 [SQL準拠]カタログにあります。 FOREIGN KEYである限り 関係が定義されているので、レポートツールもそれを見つけることができます。

• ENUM 非SQLであるため、使用しないでください。 SQLでは、「列挙型」はルックアップテーブルです。

• 次のポイントは、キーの意味に関するものです。

  • キーがユーザーにとって無意味な場合は、{INT;BIGINT;GUID;etcを使用してください。 }または適切なもの;それらに段階的に番号を付けないでください。 「ギャップ」を許可します。
  • ただし、キーがユーザーにとって意味のあるものである場合は、意味のない数字を使用せず、意味のあるリレーショナルキーを使用してください。

• これで、PKの永続性に関して接線に入る人もいます。それは別のポイントです。はい、もちろん、常にPKに安定した値を使用します （そのようなものは存在せず、システムで生成されたキーは行の一意性を提供しないため、「不変」ではありません）。

  • {M,F }変更される可能性は低いです

  • {0,1,2,4,6を使用した場合 }、まあそれを変更しないでください、なぜあなたは変更したいのですか。これらの値は無意味であると想定されていました。変更する必要があるのは、意味のあるキーだけです。

  • 意味のあるキーを使用する場合は、開発者がすぐに理解できる（そして長い説明を推測できる）短いアルファベットコードを使用してください。これは、SELECTをコーディングするときにのみ理解できます。 JOINする必要がないことを理解してください すべてのルックアップテーブル。パワーユーザーにも感謝します。

• PKは、特にルックアップテーブルで安定しているため、安全にコーディングできます。

  WHERE status_code = 'O' -- Open

  する必要はありません JOIN ルックアップテーブルを取得して データ値Open 、開発者として、ルックアップPKの意味を知っている必要があります。

最後に、データベースが大きく、OLTPに加えてBIまたはDSSまたはOLAP関数をサポートしている場合（適切に正規化されたデータベースで可能）、ルックアップテーブルは実際にはディメンションファクトのディメンションまたはベクトルです。 分析。そこになかった場合は、そのような分析を実装する前に、そのソフトウェアの要件を満たすために追加する必要があります。

• 最初からデータベースに対してこれを行う場合は、後でデータベース（およびコード）をアップグレードする必要はありません。

あなたの例

SQLは低水準言語であるため、特にJOINに関しては、面倒です。 。それが私たちが持っているものなので、私たちはただ負担を受け入れてそれに対処する必要があります。サンプルコードは問題ありません。しかし、より単純なフォームでも同じことができます。

レポートツールは以下を生成します：

SELECT p.*,
       s.name
    FROM posts  p, 
         status s
    WHERE p.status_id = s.status_id 
    AND   p.status_id = 'O'

別の例

銀行システムの場合、意味のある短いコードを使用します（意味があるため、季節によって変更せず、追加するだけです）。たとえば、（慎重に選択された、ISO国コードと同様の）ルックアップテーブルが与えられます。 ：

Eq   Equity
EqCS Equity/Common Share
OTC  OverTheCounter
OF   OTC/Future

このようなコードは一般的です：

WHERE InstrumentTypeCode LIKE "Eq%"

また、GUIのユーザーは、
{Equity/Common Share;Over The Counterを表示するドロップダウンから値を選択します。 }、
{Eq;OTC;OFではありません }、{M;F;Uではありません }。
ルックアップテーブルがないと、アプリでもレポートツールでもそれを行うことはできません。