どのようにリバースの組み合わせを許可しないコンポジットプライマリキーを

Question

私は、アプリケーションのための友人リストを構築していると私はそれができるようにテーブル上のキー/インデックスを定義することが可能かどうか疑問に思っていたキーの逆の組み合わせは許されません。

たとえば、のは、表には、このような列を持っているとしましょう：

user_id1, user_id2, status, [..timestamps] 

主キーがuser_id1とuser_id2で作られた複合キーです。今のところ特別なものはありません。あなたはこれに類似したデータ格納しますがあります

+----------+-----------+----------+---------------------+---------------------+ 
| user_id1 | user_id2 | status | created_at   | updated_at   | 
+----------+-----------+----------+---------------------+---------------------+ 
|  3 |   1 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
|  2 |   3 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
+----------+-----------+----------+---------------------+---------------------+ 

をしかし、この方法では、それぞれuser_id1とuser_id2ため1, 3または3, 2を挿入するために否定する何の制約が存在しない - そうのように：この中

+----------+-----------+----------+---------------------+---------------------+ 
| user_id1 | user_id2 | status | created_at   | updated_at   | 
+----------+-----------+----------+---------------------+---------------------+ 
|  3 |   1 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
|  2 |   3 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
|  1 |   3 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
|  3 |   2 | 1  | 0000-00-00 00:00:00 | 0000-00-00 00:00:00 | 
+----------+-----------+----------+---------------------+---------------------+ 

誰がuser1かuser2かどうかは関係ありません。重要なのはリンクされているかどうかです。重複は必ずしもコードを破壊するとは限りませんが、MySQLでもルールを適用するとよいでしょう。

Answer 1

あなたが本当にuser_id1で、どれがuser_id2あるユーザー気にしないので、私はちょうどuser_id1が低くIDであることを、任意の決定を下すだろう（もちろん、挿入時にアプリケーションが2をソートすることを確認してください！） 。

この方法で、あなたは、2つの制約と一意性を強制することができます - まず、あなたのような複合主キーが提案：

ALTER TABLE friendship 
ADD CONSTRAINT friendship_pk 
PRIMARY KEY (user_id1, user_id2) 

第二に、あなたはuser_id1は確かに小さいIDであることを確認するために検査制約が必要になります上記のように：

ALTER TABLE friendship 
ADD CONSTRAINT friendship_ids_check 
CHECK (user_id1 < user_id2)