テーブル主キー

今かかわっているプロジェクトでのDB設計の話。
これは、前のプロジェクトでDB屋さんともめた内容でもあるのだが、主キーをどうするか。データ設計を行う際に、概念上の主キーというものがあり、それはその概念の中心属性であり、たいていは複合主キーとなることが多い。DB屋さんはこれをそのまま物理設計まで持ち込む。だから、テーブル構造というのは基本的に複合主キーとなっていることが多い。
まあ、これはこれでひとつのやり方なのだが、私はアプリケーションの開発(コーディング)、特にWEBアプリとなると、この複合主キーというのが扱いにくい。そこで、内部コードを作成して、主キーをこの内部コードで統一してしまう。概念上の主キーはこの内部コードにぶらさがった形になる。しかも、この内部コード自体は意味のない数字なので、RDBMSのシーケンス機能を使って一意を保障する。
この方式だと、たとえば一覧画面があってそこから詳細画面を表示する際に、その表示したい内容の内部コードをPOST/GETすればよい。非常に管理が楽になる。
一方で、今かかわっているプロジェクトは、複合主キーでDBが組まれている。ひどい場合、主キーだけで10カラムぐらい消費する。確かに、これだとテーブル構成を見るだけでこのテーブルで表現したい概念の中心属性が一目瞭然でわかりやすい一方で、先の例でいくと、詳細画面を表示する際にも主キー群を例えばハイフンでつなげた識別IDなるものを作成の上で、それをPOST/GETしないといけない。さらに受けてのプログラムではハイフンで文字列を分割の上で主キー群を複製することになる。手間がかかる!実際はプログラマが大変なだけで、設計担当の私としては単に書面にそう記述するだけだからたいした手間じゃないのだが、非常に気持ち悪い。まあ、私がかかわった時点でほとんどのテーブル構造が決定していたのだから、仕方がない。
あきらめるか。