0

ルックアップ テーブルがあり、ケース 12 と 20 のような値の組み合わせを挿入しました。心配ですが、これが悪い習慣なのかどうかはわかりません。では、これがどのように有害になる可能性があるのでしょうか?

PK.........Name   
1.............A

2.............B

4.............C

8.............D

12............C&D

16............E

20............C&E
4

2 に答える 2

2

あなたの説明からは、何が問題なのかを正確に判断することはできません。ただし、[名前] 列に単なる名前ではない値が含まれている場合、設計は正規化規則に違反しています。

一意性の定義はあいまいになります。あなたの例では、リストのどこに重複が存在するかをどのように判断できますか (E、C&E、E&C、C)? (C&E) は (E&C) と同じですか?

あなたの例を拡張すると、Name 列もタイトルと組み合わされていると仮定すると、「Alex」と「Mrs」を探すのは難しい場合があります。たとえば、クエリをどのように記述しますか? 「Ale Mrs」または「Mrs Alex」のようなものですか? 「Mrs」という名前を持っている人が実際には Mr である場合はどうなりますか?. 列区切りはどうですか?

正確なクエリを作成できない場合、更新も問題を引き起こします。(C&E) のような値を (C) または (E) に更新することは有効ですか? すべて (C&E) を (C&D) に変更するクエリを実行できますか? (C&D) が既に存在する場合、この場合 (C&D&D) を許可しますか?

そうは言っても、結合された列の両方が必須であり、データがルックアップに厳密に使用される場合 (たとえば、単純な連絡先フォームの Country-State)、特に場合によっては、この設計はうまく機能する可能性がありますが、個人的には好きではありません。そこから得られる真の価値はないからです。

于 2013-11-03T09:15:01.357 に答える
0

C、 、Dなどの値がデータ管理の観点からアトミックであるE必要があるかどうかによって異なります。

たとえば、PK = 12 の場合、D個別に照会または変更する必要がありますかC(またはその逆)? はいの場合、D内部に格納することは原子性C&Dの原則に違反するため、1NF に違反します。この場合、テーブルを 1:N の関係に分割する必要があります。

「1」テーブル:

ID
--
12

"N" テーブル ({ID, Name} がキー):

ID Name
-- ----
12 C
12 D
于 2013-11-04T11:45:07.543 に答える