MySQLの主キー

主キーとは何か、なぜそれがリレーショナルデータベースの不可欠な部分であるのかを説明します。

2つのテーブルを作成したときに、各テーブルの主キーも作成しました。

左側の SCHEMAS のノードを展開すると タブをクリックすると、各テーブルの下にリストされている主キー（および外部キー-次のキーに移動します）が表示されます。

添付のスクリーンショットが示すように、 インデックス ノードには任意のインデックス（この場合は外部キーや主キー）が含まれています。これらの主キーと外部キーは、テーブルの作成時にコードで指定したためにのみ存在します。

具体的には、PRIMARY KEY (FruitId)を使用しました FruitId を作成します Fruit の主キーの列 テーブルで、PRIMARY KEY (UnitId)を使用しました UnitId を作成します Units の主キーの列 テーブル。

主キーとは何ですか？

主キー （一意キーとも呼ばれます ）は、一意の識別子フィールドとして割り当てられた列です。主キー列の値は、各レコードに固有です。つまり、2つのレコードがその列で同じ値を共有することはできません。

主キーフィールドの典型的な例は「ID」フィールドです。ほとんどのテーブルには、各レコードに一意の識別子を提供するIDフィールドがあります。例としては、「CustomerId」、「ProductId」、「FruitId」などがあります。これらのようなIDフィールドがないと、データベースの機能が大幅に妨げられます。同じ名前の顧客が2人以上いる場合、どのようにして彼らの記録を見つけることができますか？すべてのレコードに固有の何かを見つけることができる可能性があるのは事実ですが、各レコードに固有のIDを提供することを主な目的とする列を作成する方がはるかにクリーンで簡単です。

プライマリは、一意であることが保証されている通常の値（書籍、製品コードなどのISBN番号）にすることも、アプリケーションまたはDBMSによって生成されて一意になるように特別に生成された値（グローバル一意など）にすることもできます。識別子、または自動インクリメント整数）。

主キーの選択

主キーの列を選択するときは注意してください。すべてのレコードに1つあること、および2つのレコードが同じ値を共有する可能性がないこと、または1つのレコードに複数の値があることを確認する必要があります。

たとえば、ユーザーの電子メールアドレスを使用すると機能する場合もありますが、一意の識別子の根拠としては十分ではありません。ユーザーは自分のメールアドレスを変更できます。ユーザーはメールアドレスを共有できます。一部のユーザーはメールアドレスを持っていない可能性があります。もちろん、ユーザーがメールアドレスを変更したり共有したりできないようにシステムを作成することはできますが、システムはあまり柔軟ではなく、ユーザーフレンドリーでもありません。

すべてのユーザーに一意のユーザー名を要求することができます。それはうまくいくかもしれません。ただし、すべての可能性について慎重に考える必要があります。ユーザーが変更または共有する可能性がある場合（過去、現在、または将来）、主キーとして使用しないでください。 「TechGuy12」が彼のアカウントを無効にした場合はどうなりますか。これは、別のユーザーが「TechGuy12」を使用できるようになったことを意味しますか？これは、アプリケーションまたは生成する必要のあるレポートにとって問題になりますか？

主キーフィールドの「一意性」について疑問がある場合は、作成されたレコードごとに増分する自動生成された番号を使用してください。