2

ここで最適なソリューションが何であるか疑問に思っています。

正規化されたデータベースがあるとします。システム全体の主キーは varchar です。私が疑問に思っているのは、このvarcharをintに関連付けて正規化するか、そのままにしておくべきですか? varchar のままにしておく方が簡単ですが、より最適な場合があります

たとえば、私は持つことができます

People
======================
name      varchar(10)   
DoB       DateTime    
Height    int  

Phone_Number
======================
name      varchar(10)   
number    varchar(15)

または私が持っている可能性があります

People
======================
id        int Identity   
name      varchar(10)   
DoB       DateTime  
Height    int  

Phone_Number
======================
id        int   
number    varchar(15)

もちろん、他にもいくつかの一対多の関係を追加してください。

皆さんはどう思いますか？どちらが優れているのか、その理由は?

4

7 に答える 7

10

大規模な実世界のデータベース アプリケーションを開発したことのある大多数の人々は、代理キーが唯一の現実的な解決策であると言うでしょう。
学術界が反対することは承知していますが、それが理論上の純粋さと実用性の違いです。

一部のテーブルに複合主キーがある場合、非代理キーを使用するテーブル間で結合を行う必要がある適切なサイズのクエリは、すぐに維持できなくなります。

于 2008-09-27T19:28:47.010 に答える
7

名前を主キーとして本当に使用できますか? 同姓同名の可能性が高いのではないですか？

name 属性を主キーとして使用できるほど幸運な場合は、必ずそれを使用してください。ただし、多くの場合、customer_id などのように何かを作成する必要があります。

最後に、「NAME」は少なくとも 1 つの DBMS の予約語であるため、フルネームなど、別のものを使用することを検討してください。

于 2008-09-27T17:59:44.417 に答える
6

あらゆる種類の非合成データ (つまり、アプリケーションによって生成されたものではなく、ユーザーからのもの) を PK として使用することには問題があります。カルチャ/ローカリゼーションの違い、大文字と小文字の区別 (および DB 照合に応じたその他の問題) について心配する必要があり、ユーザーが入力したデータが変更された場合などにデータの問題が発生する可能性があります。

非ユーザー生成データ (シーケンシャル GUID (または、DB がサポートしていない場合やページ分割を気にしない場合は非シーケンシャル) または ID int (GUID が必要ない場合)) を使用する方がはるかに簡単で、はるかに安全です。

重複データについて: 非合成キーを使用してそれを防ぐ方法がわかりません。ユーザーが「Bob K. Smith」、「Smith、Bob」、「bob smith」などの代わりに「Bob Smith」と入力する問題がまだ残っています。キーが合成かどうかに関係なく、重複管理が必要です (ほとんど同じです)。または非合成および非合成キーには、合成キーがきちんと回避する他の多くの潜在的な問題があります。

多くのプロジェクトではそれについて心配する必要はありません (たとえば、厳密に制約された照合の選択により、それらの多くが回避されます) が、一般的に私は合成キーを好みます。これは、オーガニック キーで成功できないと言っているわけではありません。

于 2008-09-27T18:15:24.550 に答える
3

VARCHAR が大きければ、データベース全体でかなりの量のデータが複製されていることに気付くでしょう。一方、数値 ID 列を使用した場合は、外部キー列を他のテーブルに追加するときに、ほぼ同じ量のデータを複製していません。

さらに、テキストデータは比較の点で王様の苦痛です。WHERE id = user_id と WHERE name LIKE inputname (または同様のもの) を実行すると、作業がはるかに簡単になります。

于 2008-09-27T18:05:17.600 に答える
1

他の人が言及していないように見えることの 1 つは、int フィールドでの結合は、varchar フィールドでの結合よりもパフォーマンスが優れている傾向があるということです。

また、(人や企業の) 名前を使用するよりも常に代理キーを使用することは間違いありません。たとえば、私たちのデータベースには、同じ名前のインスタンスが 100 を超える 164 の名前があります。これは、名前をキー フィールドとして使用することの危険性を明確に示しています。

于 2008-09-27T20:56:41.637 に答える
1

「名前」フィールドが主キーとして本当に適切な場合は、それを行います。その場合、代理キーを作成してもデータベースは正規化されません。外部キーの重複した文字列がいくつか取得されますが、これは正規化の問題ではありません。これは、代理キーと同様に、FK 制約が文字列の整合性を保証するためです。

ただし、「名前」が何であるかを説明していません。実際には、文字列が主キーとして適切であることはほとんどありません。人の名前の場合、複数の人が同じ名前を持つことができるため、PK として機能しません。名前を変更することができます。

于 2008-09-27T19:46:39.837 に答える
1

元の質問は正規化の問題ではありません。あなたが述べたように、正規化されたデータベースがある場合、正規化の理由でデータベースを変更する必要はありません。

あなたの質問には本当に2つの問題があります。1 つ目は、主キーおよび外部キーとして使用するのに int と varchar のどちらが適しているかです。2 つ目は、問題定義で与えられた自然キーを使用できるかどうか、または自然キーの代わりに合成キー (代理キー) を生成する必要があるかどうかです。

ints は varchars よりも少し簡潔で、インデックス処理などに対して少し効率的です。しかし、違いは圧倒的ではありません。おそらく、これだけに基づいて決定を下すべきではありません。

提供された自然キーが実際に自然キーとして機能するかどうかという問題は、はるかに重要です。「名前」列の重複の問題だけが問題ではありません。人が改名した場合にどうなるかという問題もあります。この問題は、あなたが示した例ではおそらく表面化していませんが、他の多くのデータベース アプリケーションでは表面化しています。例としては、学生が受講したすべてのコースの 4 年間にわたる成績証明書があります。女性は 4 年以内に結婚して名前を変えるかもしれませんが、今は行き詰まっています。

名前を変更せずにそのままにしておく必要があります。この場合、名前は現実の世界と一致しなくなります。または、その人が受講したすべてのコースでさかのぼって名前を更新する必要があります。これにより、データベースは当時作成された印刷された名簿と一致しなくなります。

合成キーを決定する場合は、アプリケーションが合成キーの値をユーザー コミュニティに公開するかどうかを決定する必要があります。これは別のワームの缶詰であり、この議論の範囲を超えています.

于 2008-09-28T19:40:09.220 に答える