列を主キーとしてマークするのはいつですか？

Question

私はテーブルのように持っている：私はそれについて考える

// cookies 
+----+---------+-------------------+------------+ 
| id | user_id |  token  | expire | 
+----+---------+-------------------+------------+ 
| 1 | 32423 | dki3j4rf9u3e40... | 1467586386 | 
| 2 | 65734 | erhj5473fv34gv... | 1467586521 | 
| 3 | 21432 | 8u34ijf34t43gf... | 1467586640 | 
+----+---------+-------------------+------------+ 

数日。私はidの列にする必要はないと思います。現在idの列はPKであり、ユニークなインデックスをtokenという列に付けて検索すると、ユニークで高速な列になります。

今、知りたいのは、idの列をテーブルから削除し、tokenの列をPKにすることができますか？それは普通ですか？

正直に言うと、私はPKとしてtoken列を選択するためにそれは奇妙ですので、私は、これまでid列（それは常にPKをされている）せずにテーブルを作成したことがありません。

Answer 1

tokenが広いvarcharである限り、私はあなたが既に持っているAI int PKに固執します。結合はより速くなります。あまりにも挿入されます。更新は、なぜその列が更新されてインデックスツリーの変更が強制されるのかと同じ速度になる可能性があります。ただし、挿入子は、ワイドvarcharをインデックスツリーにドラッグしないことで、子関係の方が高速です。

これは優先度と読みやすさにもなります。読みやすさに関しては、そのようなvarcharではそれがほとんどありません。 「シューズ」のようなカテゴリーではない。それは悲惨な読めない人間以外の形です。読みやすくするために、tokenをPKにすることについての議論はほとんどありません。しかし、時には、それはわずかに有用かもしれない。あなたはコンポジット内の他の仲間の列（あなたが持っていることを選択できる追加の索引）を選択したPKを組み合わせ起動すると

追加の複合（マルチカラム・インデックス）

は、薄いintはに非常に明らかになるであろう最良の選択となる。適度に大きなデータセットでも。

Answer 2

一般的に私たちは主キーのIDを優先しますが、プライマリキーはnullでなくてはならず、テーブルの残りのレコード（列）を一意に識別する必要があるということです。主キーとしてのトークンは簡単に作成できますが、他のテーブルに依存しないようにしてください（Id）。 なので、任意のレコードをフェッチする必要があるときはいつでも、トークンを使って簡単にフェッチできます。