212

これは、私が取り組んでいる激しいセットアップを大幅に単純化しすぎたものです。table_1両方ともtable_2、IDとして自動インクリメントの代理主キーを持っています。とinfoの両方に関する情報を含むテーブルです。table_1table_2

table_1 (id, field)  
table_2 (id, field, field)
info ( ???, field)

infoとからのIDの複合の主キーを作成する必要があるかどうかを判断しようとしていtable_1ますtable_2。私がこれを行うとしたら、これらのどれが最も理にかなっていますか？
（この例では、ID11209とID437を組み合わせています）

INT(9)11209437 （なぜこれが悪いのか想像できます）
VARCHAR (10) 11209-437
DECIMAL (10,4)11209.437

または、他の何か？

これをMYSQLMYISAMDBの主キーとして使用しても問題ありませんか？

4

8 に答える 8

399

複合（複数列）キーを使用します。

CREATE TABLE INFO (
    t1ID INT,
    t2ID INT,
    PRIMARY KEY (t1ID, t2ID)
)

このようにして、t1IDとt2IDをそれぞれのテーブルを指す外部キーとして使用することもできます。

于 2011-04-29T18:47:09.243 に答える
24

「info」テーブルの主キーを、他のテーブルの2つの値の合成にはしません。

他の人は理由をより明確に表現できますが、実際には2つの情報で構成されている列があるのは間違っていると感じます。何らかの理由で2番目のテーブルのIDを並べ替える場合はどうなりますか？いずれかのテーブルの値が存在する回数をカウントしたい場合はどうなりますか？

私は常にこれらを2つの異なる列として保持します。mysql ... PRIMARY KEY（id_a、id_b）...で2列の主キーを使用できますが、2列の一意のインデックスを使用し、主キーフィールドを自動インクリメントすることをお勧めします。

于 2011-04-29T19:27:45.200 に答える
20

構文はCONSTRAINT constraint_name PRIMARY KEY(col1,col2,col3)たとえば::

CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)

上記の例は、たとえば::テーブルの作成中に書き込みを行う場合に機能します。

CREATE TABLE person (
   P_Id int ,
   ............,
   ............,
   CONSTRAINT pk_PersonID PRIMARY KEY (P_Id,LastName)
);

この制約を既存のテーブルに追加するには、次の構文に従う必要があります

ALTER TABLE table_name ADD CONSTRAINT constraint_name PRIMARY KEY (P_Id,LastName)
于 2013-03-26T16:58:54.923 に答える
13

すでにテーブルを作成していると仮定すると、このクエリを使用して複合主キーを作成できます

alter table employee add primary key(emp_id,emp_name);
于 2017-08-23T06:16:29.983 に答える
5

個人的なデザインの好みとは別に、複合主キーを利用したい場合があります。テーブルには、一意の組み合わせを提供する2つ以上のフィールドが含まれる場合がありますが、必ずしも外部キーを使用する必要はありません。

一例として、米国の各州には一連の独自の議会地区があります。多くの州が個別にCD-5を持っている場合がありますが、50の州のいずれにも複数のCD-5が存在することはなく、その逆も同様です。したがって、マサチューセッツCD-5の自動番号フィールドの作成は冗長になります。

データベースが動的なWebページを駆動する場合、2つのフィールドの組み合わせでクエリを実行するコードを記述することは、自動番号付きキーを抽出/再送信するよりもはるかに簡単です。

したがって、元の質問には答えていませんが、アダムの直接の答えには確かに感謝しています。

于 2013-10-17T11:15:26.000 に答える
4

複合主キーは、ファクトテーブルとの多対多の関係を作成したい場所に必要なものです。たとえば、多数のプロパティを含むホリデーレンタルパッケージがあるとします。一方、この物件は、単独で、または他の物件と一緒に、いくつかの賃貸パッケージの一部として利用できる場合もあります。このシナリオでは、プロパティ/パッケージファクトテーブルを使用して、プロパティとレンタルパッケージの関係を確立します。プロパティとパッケージの間の関連付けは一意であり、property_idとプロパティテーブルおよび/またはpackage_idとパッケージテーブルを使用してのみ結合します。各関係は一意であり、auto_incrementキーは他のテーブルにはないため、冗長です。したがって、複合キーを定義することが答えです。

于 2013-03-12T18:43:43.850 に答える
2 
CREATE  TABLE `mom`.`sec_subsection` (

  `idsec_sub` INT(11) NOT NULL ,

  `idSubSections` INT(11) NOT NULL ,

  PRIMARY KEY (`idsec_sub`, `idSubSections`) 

);
于 2012-02-07T08:32:51.780 に答える
1

@AlexCuseこれをコメントとして回答に追加したかったのですが、コメントに改行を追加しようとして何度も失敗したため、あきらめました。

とはいえ、t1IDはtable_1で一意ですが、INFOテーブルでも一意になるわけではありません。

例えば：

Table_1には次のものがあります 。Id
フィールド1A2 B

Table_2には次のものがあります。Id
フィールド
1X2
Y

INFOは次のように
なります。t1IDt2IDフィールド
11いくつかの
12データ21入力
-各22
行

したがって、INFOテーブルで行を一意に識別するには、t1IDとt2IDの両方が必要です。

于 2014-06-05T13:45:03.957 に答える