私のデータベースでは、多くのテーブルに「状態」フィールドがあり、特定のエンティティが陥る状態を表しています。この種のものにはルックアップ テーブルを使用するように言われましたが、正確なメカニズムはわかりません。誰かがこれらの点を明確にすることができますか?
整合性はどのように維持されますか? (つまり、状態テーブルの値のみが他のテーブルに移動するようにするにはどうすればよいですか?)
州名は他のテーブルに入りますか、それとも州テーブルの州 ID は他のテーブルに入りますか?
私のデータベースでは、多くのテーブルに「状態」フィールドがあり、特定のエンティティが陥る状態を表しています。この種のものにはルックアップ テーブルを使用するように言われましたが、正確なメカニズムはわかりません。誰かがこれらの点を明確にすることができますか?
整合性はどのように維持されますか? (つまり、状態テーブルの値のみが他のテーブルに移動するようにするにはどうすればよいですか?)
州名は他のテーブルに入りますか、それとも州テーブルの州 ID は他のテーブルに入りますか?
1 - FOREIGN KEY 制約と呼ばれるものを使用して整合性が維持されます。合理的なシナリオでは、次の 2 つのテーブルを実行する必要があります。
Table Name: STATE_CODE
ID DESCRIPTION
=================
1 Alabama
2 Arkansas
...
50 Wyoming
Table Name: CUSTOMER
=====================
CUST_ID CUST_NAME CUST_STATE
100 AAA Company 1 --they are in Alabama!
200 ZZZ Company 50 --they are in Wyoming!
これはあなたの質問 #2 に答えます: この例では、完全な名前ではなく州コードが CUSTOMER テーブルに入ります。
この種の構造を既存のレイアウトに適用する典型的なスクリプトは次のようになります。
--first, create the lookup table
CREATE TABLE STATE_CODE(
ID INTEGER NOT NULL
,DESCRIPTION VARCHAR(100) NOT NULL
,PRIMARY KEY(ID)
);
--now add a reference to the lookup table inside your existing table
--the REFERENCES part will **force** entries
--to have a matching entry in STATE_CODE
ALTER TABLE CUSTOMER ADD STATE_CODE_ID REFERENCES STATE_CODE(ID);
そして、これはあなたの質問 #1 に答えます: その "REFERENCES" コマンドは、CUSTOMER.STATE_CODE のすべてのエントリが STATE_CODE テーブルに対応するエントリを持つように強制する外部キー制約を作成します。これを設定した後、誰かがこれを試した場合:
INSERT INTO CUSTOMER(CUST_ID,CUST_NAME,CUST_STATE)
VALUES(9000,'Martians',74837483748);
その後、エラー メッセージが表示され、その誤ったデータが入力されることはありません (もちろん、コードが 74837483748 の状態が実際にあった場合を除きます)。
答え:
整合性は、外部キー制約によって維持されます。
外部キー制約により、子テーブルが指定された列で許可する値のみが、親テーブルの指定された列から取得されることが保証されます。
結合/さまざまなデータベース操作のために、パフォーマンスが向上するため、可能な限り最小のデータ型が推奨されます。
たとえば、INT は 4 バイトかかりますが、VARCHAR2(4+) はそれ以上かかります。パフォーマンスの観点からは、VARCHAR2(4+) よりも INT を使用する方が高速になります。しかし、2 つの列が必要です。1 つは主キーとして機能し、もう 1 つは人間が読める説明です。このアプローチにより、既存のレコードに影響を与えずに説明を変更できます。
これは、主キー (および最終的には外部キー) として使用するのに最適なものについて、人工/代理および自然キーに関する議論につながります。