以前にも触れたのですが、RDBのテーブルに主キー設定を必須にしている開発標準を見かけます。
データ行数が増減しない、固定のテーブルは結構あるものです。
性別テーブル、部署テーブル、得意先ランクテーブル、商品類別テーブルその他諸々。
少ないテープルたと、2行、多くても100行程度のテーブルはあります。
プロジェクトによっては、一つの汎用マスターに纏めているシステムもありますが、私は嫌で、各々1つのテーブルにします。
(RDBのテーブル管理が1次元なので、管理しづらい面はありますが)
引用が多いテーブルでも、行数が少ない場合は、索引を貼るメリットは薄いです。速度面でも、貼らない方が早いケースもあります。
フォーリンキーで結合していたり、更新系の部分を生成フレームワークに依存する時は、キーが必要になるので、主キー設定を必須にしているのだと思います。
性別テーブルやランクテーブルは、更新(保守)することって無いでしょう。更新しないテープルと頻繁に更新するマスターは別扱いにした方が、楽できそうです。
多くの索引を貼っているテーブルを見かけます。機会性能が向上したので、負になる部分が隠れてしまうのでしょうか。顧客マスターの性別項目に索引を貼っているのもありました。担当者項目、顧客ランク項目にも張ってましたね。
重複を許す索引を設定するとき、キー値に該当するレコードは最大でも全体量の10%以下(数字は説が色々あるようです)が望ましいと言われています。
「索引を貼ると高速化する」と信じる前に、索引を全部はずして、速度比較してみると意外なことが判ります。
追加更新系やバッチが早くなったり、エントリーレスポンスは殆ど変わらなかったり。サーバー負荷が軽くなったり(少ないでしょうが)
SQL文の組み方で速度差は10倍以上の開きがあるのは、有名な話です。
索引に頼らないで、高速化できれば、そのほうがDB構造もスッキリするし、保守性も高まります。
「ネック順の上位20%を改善したら、80%は解決する」という法則に該当しそうです。