-3

重複の可能性:
主キーの選択方法

次の属性を持つ User クラスがあります。

  • ユーザー名 (固有)
  • パスワード
  • 電子メール (固有)
  • ファーストネーム
  • 苗字
  • 年

Username と Email は、User のインスタンスを一意に識別します。私のデータベースでは、これらを主キーとして使用するか、インスタンスごとに異なる一意の識別子を生成する必要があります。私の知る限り、 ではSELECT、文字列の比較は数値の比較よりも遅くなります。次に、自己割り当ての int、long、double などを使用したり、AUTO_INCREMENTユーザーの ID 列で使用したりしないでください。UUID の使用についてはどうですか (これも長い文字列の問題です)。私の質問は、後で追加する可能性のある他のすべてのドメイン クラスにも当てはまります。

4

3 に答える 3

1

インデックスを生成するときは、次のヒントに従ってみます: http://cherry.world.edors.com/CzyAhL90b5RA (MySQL インデックスのヒントのリスト)

また、ユーザー名または電子メールを使用すると、データベース内の他のテーブルが外部キーで「めちゃくちゃ」になり、それらのテーブルのインデックス作成も難しくなります。int または long にして、AUTO_INCREMENT を使用します。

于 2012-10-12T21:20:42.757 に答える
1

主キーは他のフィールドとは別にする必要があり、ビジネス上の価値がなく、一意の整数である必要があります。

例: ある企業が、社会保障番号を含む「ユーザー」テーブルを作成します。これらは、各人に固有のものでなければなりません。ただし、ある時点で、ユーザーが入力した ssn のキーが間違っています。誤って入力された番号はまだ存在せず、レコードは保存されます。しばらくして、別のユーザーが自分の ssn を入力しようとしましたが、実際には以前に入力ミスしたのと同じ番号です。会社自体がこの問題を見つけて解決するまで、ユーザーは実際にプロファイルを保存して続行することができない場合があります。この問題を考慮して、会社はこの時点で ssn の「一意」の制約を緩和することを決定しました。ssn が主キーでない場合、これは比較的簡単に実行できます。一意の制約を削除するだけです。主キーが ssn の場合、これは難しくなります。

フィールドを auto_increment として定義すると、mysql がそれを処理します。

CREATE TABLE Persons
 (
 person_id int NOT NULL AUTO_INCREMENT,
 LastName varchar(255) NOT NULL,
...
于 2012-10-12T21:18:54.613 に答える
0

代理キーではなく、一意の列で構成される複合主キーを検討してください。これには、一意性の要件に基づいてデータの整合性を維持するという追加の利点があります。

于 2012-10-12T21:28:23.903 に答える