「キー列」の定義がだいじ
from 雑に読む「達人に学ぶDB設計徹底指南書」
「キー列」の定義がだいじ
いわゆるUUIDのことかな
UUIDに限りません。ある特定の列の値を一意に決定できれば大丈夫です
ある特定の列の値を決定するための列（複数列でも良い）を理解するために変な例をたくさんあげてみる
こういうテーブルがあったとする
例
| 社員番号 | 入社年 | 名前 |
| 1 | 2000 | 田中太郎 |
| 2 | 2001 | 田中次郎 |
| 3 | 2002 | 田中太郎 |
ここでの社員番号は連番なので一番キーとして便利
社員番号1番の人は2000年入社の田中太郎さんしかいない
ここはわかる
入社年も被っていないから（もし、もう社員が増減しないという非現実的な仮定を置くなら）キーにできる
2000年入社の人はここでは1人しかいないので、「2000年入社の人」で社員番号1番の田中太郎さんが一意に定まる
注意：非現実的な仮定なので、普通はキーにしません（多分どんなシステムでもしない）。あくまで理解のための例
仮に2000年入社の人がもう一人増えたら、キーにはできないということですね
入社年がこのテーブルにおいて一意でなくなっちゃうから
そうですね
ところで、田中太郎さんは2人いるので名前の列は（単体では）キーにならない
「田中太郎」という情報だけでは社員番号1なのか3なのかわからない
でも「入社年と名前」の組み合わせなら重複がないので社員番号を一位に定めるキーになる
2000年入社の田中太郎さんは社員番号1番の人しかいない
今回の例だと入社年だけで決められちゃうからそれに何足しても一意にに決まるので例が悪かった
なるほど
みたいな感じ
「一意に定まる」というのが重要なんだなあ
これは一つの属性だけに限らず、複数の属性で指定できる
(使ってる語彙が正しくなさそうだけれども)
キーにはいろいろな名前がついているのですが、複雑になるので後から出てくるのかな
社員名簿があるとして、全員違う名前だから名前をキー列にしたろ！ってするとひどいことになるんだろうな
あとから同じ名字の人や名前の人が入ってきて一意性が保てなくなる
だからそういう列はキーにしてはならない(単独で)
そういうのを考えるのが面倒なので連番id列を作るのが普通だと思います
UUID列を作るのが普通だと思います
そしてそれがアンチパターンになることも
まだ理解出来ない
これは実際にやるような人が考えることなのでとりあえず無視してOK
ここでのキーはスーパーキーかな？
いつか再訪する
複数列を使ってもいい