テーブルを設計するとき、名称だけで、すでに一意になる場合がある
たとえば、会社の場合、部名と課名をあわせると一意になるときがある
（って、ならないと困るよ！違う部で同じ課名はOKだけど、同じ部で、同じ課の名前で、実態が違うって言ったら、わかんなくなってしまう（＞＿＜！）
このような場合、IDを振らなくても、名称を主キーにするケースがある
（もちろん、同姓同名が合ったり、課名変更があるので、主キーにしたくないというケースがあるのは別。そうではなく、まず、名称が、そう変わる危険もない場合。種別コードなどで、特にありえる）。
上記のケースにおいては、正規形の立場をとれば、IDと名称は、従属関係になるので、IDはいらないということになる。
そこで、このとき、IDをもつことの有利不利について、ちょっとまとめ。
■IDを振ったほうがいい理由
・ハッシュテーブルのとき、連番のほうが、きれいに散る
ハッシュキーを計算式で求める場合、キーが一様のほうがきれいに散る（シノニムが出来にくい）が、名称だと、そーいかないかも・・・
・文字列を検索することになる
それって、おそくない？
■IDを振らないほうがいい理由
・JOINが多くなる。
ユーザーにIDを見せるわけにはいかない場合、名称を入力することになる。
その場合、たとえば、部、課、係とあったとき、
部名、課名、係名を入力してもらったら、
もし、IDを振らず、名称がキーなら、係名テーブルを検索するだけでOK
（部名、課名は、係名テーブルの外部キーとして入っている）
それに対し、IDを振った場合、部名テーブル、課名テーブル、係名テーブルをJOINし、そのテーブルから検索することになる。
このように、JOINが増える危険がある（実務上、JOIN数には限度がある）
ふとおもいついたのは、こんなかんじかな・・
アクセス
トータル
ランキング
