0

ここでは、自動インクリメント ID キーが使用できないが、データ ディクショナリで id を見た ER 図を見てきました。主キーとして使用される属性がデータ ディクショナリで一意のキーとして使用され、自動インクリメント ID が次のように使用されます。 ER図にない主キー.なぜこれが起こるのですか?

field    KEY              other                     NULL?

id      Primary key      auto increment             Not null

Name    Unique key                                  Not Null
....     ...........                                 ...........

ER図に表示せずに主キーIDが使用される理由と、ER図の主キーがデータ辞書のUNIQUEキーとして使用される理由を誰でも言うことができますか?

4

3 に答える 3

1

原則として、主キーとその他のキーに違いはありません。すべてのキーは、「プライマリ」キーとして指定するかどうかに関係なく、一意であり、null 不可である必要があります。そのため、複数の候補キーがある場合に任意の 1 つの主キーを指定することは、設計者が望んでいるほど重要な、ある程度柔軟で非公式な概念です。おそらく、あなたが見ている違いは、異なる意見や意図された用途を反映しているだけです. もちろん、別の可能性としては、誰かが単純なミスを犯した可能性があります。

于 2012-05-27T09:38:27.743 に答える
0

可能性のある ID は代理キーであり、NAME は自然なものであり、代理キーを使用する設計には多くの利点があります。たとえば、それらは（そうあるべきです）不変です。

ID でリンクされた別のテーブルがある場合は、参照整合性を壊したり、依存テーブルのキーを再生成したりすることなく、名前を変更できます (たとえば、スピル メスティックを修正します)。

もう 1 つは、Name をもう一意にしたくない場合です。おそらく、コンテキスト用に別の列を追加し、Name と Context を複合一意キーにします。関連するすべてのテーブルを作り直すのがどれほど大変なことか想像してみてください。

ただし、サロゲートのルール 1 は公開しないでください。

于 2012-05-27T01:08:18.683 に答える
0

I'd の使用は、一貫性のためかもしれません。一部のフレームワークでは、すべてのテーブルが主キーとして id を持っていると想定しています。これにより、テーブルの操作が標準化/簡素化されます。しかし、ER図からの「実際の」主キーは有効なキーになるので、UNIQUEとしてフラグを立ててこれをDBに通知してみませんか?

于 2012-05-27T00:28:54.640 に答える