2

私のデータベースには、ユーザーに関する情報を含むユーザーのリストがあり、ユーザーが他のユーザーを候補リストに追加できる機能もあります。私のユーザー情報は、ユーザー ID の主キーを持つ 1 つのテーブルに保存され、ショートリスト用に別のテーブルがあります。ショートリスト テーブルは、2 つの列を持ち、基本的に名前のペアのリストになるように設計されています。したがって、特定のユーザーのショートリストを見つけるには、最初の列の ID が特定の値である 2 番目の列からすべての名前を取得します。

問題は、このような多くの情報源によると、すべてのテーブルに主キーが必要ですか? データベースのすべてのテーブルに主キーが必要です。

このソースによるとhttp://www.w3schools.com/sql/sql_primarykey.asp - データベース内のエントリを一意に識別する主キー。だから私の質問は：

  1. データベース内のテーブルの何が問題になっていますか? なぜ主キーが必要なのですか?

  2. 主キーを与えるにはどうすればよいですか？各エントリが一意の ID を持つように、新しい自動インクリメント列を作成するだけですか? これにはあまり意味がないようです。または、ショートリストを表す複数のエントリを別のテーブルの別のエンティティにカプセル化し、それをリンクしますか? 私は本当に混乱しています。

4

6 に答える 6

2

行が重複しているテーブルは、リレーションを適切に表現していません。これは行のセットではなく、行のバッグです。これを実現させると、最終的にはカウントがオフになり、合計がオフになり、平均がオフになります。つまり、データを使用しようとすると、データから紛らわしいエラーが発生します。

主キーを宣言することは、アプリケーションプログラムの1つがミスを犯した場合でも、重複する行がデータベースに入るのを防ぐための便利な方法です。取得するインデックスは副作用です。

テーブル内の単一行への外部キー参照は、任意の候補キーを参照することによって行うことができます。ただし、これらの候補キーの1つを主キーとして宣言し、すべての外部キー参照が主キーを参照するようにすると、はるかに便利です。丁寧なデータ管理です。

実世界のエンティティとそのエンティティのテーブル内の対応する行との間の1対1の対応は、DBMSの領域を超えています。既存のエンティティの新しい行を作成せず、一部の新しいエンティティがクラックをすり抜けないようにすることで、その対応を維持するのは、アプリケーションとデータプロバイダーの責任です。

于 2012-09-01T12:52:31.547 に答える
2

この特定のケースでは、同じユーザー ID のペアがshortlistテーブルに複数回格納されても意味がありません。結局のところ、そのテーブルはセットをモデル化しており、要素はセットに含まれているか含まれていないかのどちらかです。セット内に要素を「2 回」持つことは意味がありません1。これを防ぐには、これら 2 つのユーザー ID フィールドで構成される複合キーを作成します。

この複合キーも主になるか、別のキー (代理主キーとして機能する) を持つかは別問題ですが、いずれにしてもこの複合キーが必要になります。

クラスタリングをサポートするデータベース (別名、インデックス構成テーブル)の下では、PK は多くの場合、クラスタリング キーでもあることに注意してください。これは、パフォーマンスに重大な影響を与える可能性があります。

1 Mutiset とは異なります。

于 2012-09-01T03:42:56.693 に答える
2

行が一意である場合、データベースに依存する可能性がありますが、2 列の主キーを持つことができます。次に例を示します。

CREATE TABLE my_table
(
col_1 int NOT NULL,
col_2 varchar(255) NOT NULL,
CONSTRAINT pk_cols12 PRIMARY KEY (col_1,col_2)
)

すでにテーブルがある場合、例は次のようになります。

ALTER TABLE my_table
ADD CONSTRAINT pk_cols12 PRIMARY KEY (col_1,col_2)
于 2012-09-01T00:36:54.153 に答える
2

主キーは各レコードを一意に識別する必要があり、前述のように、主キーは複数の属性 (1 つ以上の列) で構成できます。まず、各レコードがテーブル内で本当に一意であることを確認することをお勧めします。第二に、主キーなしでテーブルを離れたことを理解しているので、それは許可されていないので、キーを設定する必要があります。

于 2012-09-01T00:46:45.530 に答える
1

あなたが尋ねているので、それは良い習慣ですが、いくつかの例では（データへの結合は必要ありません）、絶対に必要ではないかもしれません. ただし、最大の問題は、要件が変更されるかどうかを実際に知ることはできないため、今本当に必要なため、事後に10mレコードテーブルに追加しないことです.....

主キー（複数の列にまたがることができます）に加えて、単一のフィールドである二次候補キーを用意することをお勧めします。これにより、結合が容易になります。

まずいくつかの理論。y = f(x)HS またはカレッジ代数の関数の定義は、すべての x に対して y が 1 つだけ存在する場合にのみ、f が関数であるということを覚えているかもしれません。この場合、リレーショナル数学では、y はfunctionally dependentx 上にあると言えます。

同じことがデータにも当てはまります。小切手番号、当座預金口座番号、および金額を格納しているとします。複数の当座預金口座があり、各当座預金口座に重複する小切手番号が許可されていないと仮定すると、金額は機能的に (account, check_number) に依存します。一般に、同じものに機能的に依存し、推移的な依存関係がないデータを一緒に保存したいと考えています。通常、主キーは、主キーとして指定した機能依存関係になります。これにより、行内の残りのデータが識別されます (その識別子に関連付けられているため)。これをnatural primary key. 可能な場合 (つまり、MySQL を使用しない場合)、主キーが複数の列にまたがっていても、主キーが自然キーであると宣言するのが好きです。複数の交換可能な候補キーがある場合、これは時々複雑になります。たとえば、次のことを考慮してください。

CREATE TABLE country (
    id serial not null unique,
    name text primary key,
    short_name text not null unique
);

このテーブルでは、実際には任意の列を主キーにすることができます。3 つすべてが完全に受け入れ可能な候補キーです。国レコード (232、「米国」、「米国」) があるとします。これらの各フィールドはレコードを一意に識別するため、1 つがわかれば他のフィールドも知ることができます。それぞれを主キーとして定義できます。

また、結合のリンクに使用される単なるマシン識別子である、2 つ目の人工的な候補キーを用意することもお勧めします。上記の例では、country.id がこれを行います。これは、他のレコードを国テーブルにリンクするのに役立ちます。

候補キーを必要とする例外は、重複レコードが実際に発生する可能性がある場合です。たとえば、請求書を追跡しているとします。2 つの項目のそれぞれに 1 つずつ表示されている 2 つの項目に対して、誰かが個別に請求される場合があります。これらは同一である可能性があります。この場合、後でそのレコードに何かを結合できるようにするため、人工的な主キーを追加することをお勧めします。今はそうする必要はないかもしれませんが、将来必要になるかもしれません!

于 2012-09-02T10:27:57.217 に答える
0

複合主キーを作成します。複合主キーの詳細については、 http://www.relationaldbdesign.com/relational-database-analysis/module2/concatenated-primary-keys.phpにアクセスしてください。

于 2013-06-02T04:24:27.353 に答える