« 「コメント率50%」の謎 | トップページ | ソフトウエアの設計は協業の基礎を作ること »

2006年9月 6日 (水)

複合キーの必要性はなし?

先ごろ開かれたRailsConfでは、オープニングキーノートにおいてPragDaveが「Railsでは解決できない事項」に焦点をあてていた。その中にはエンタープライジーなことも含まれていた。たとえば、複合キーを持つような、様々なデータ構造を扱うことが必要だというのだ。

これに対するDHHの反応は、この上なく痛烈な拒絶であった。

Martin Fowler's Bliki in Japanese - エンタープライズRails

ここでいう「複合キー」が何を指すのか、はっきりとは書いてありませんが。リレーショナル・データベースのテーブルが持つ、「複数列で構成される主キー」ということにして、複合キーの必要性について、考えてみます。

まず、複合キーが「必要とされる」状況を、3点挙げてみます。

---

1) 階層構造を表現したい

これはすぐに否定できますね。
単一の主キーと外部キーの関連を使って、階層構造は容易に表現できます。

2) パーティショニングを行ないたい

例えば、複数拠点にデータベースを分散配置し、それぞれの拠点で、テーブルにデータを追加したい場合ですね。さらに、拠点で入力したデータを、「中央」に集めるような場合です。

この場合は、「パーティショニング・キー」として、拠点のIDを使用し、さらに、拠点のIDと、拠点で入力の際に付けるIDを、組み合わせて「複合キー」とします。

この場合も、「パーティショニング・キー」=「主キー」である必要はなく、「主キー以外の候補キー」を、「パーティショニング・キー」とすることができます。主キーの値は、データベースごとに独自に作れば良いでしょう。

「パーティショニング・キー」=「主キー」とすることで、単純なデータベース・レプリケーションによって、データベースを分散させることができる、というのはありそうですが。いわゆる”Auto Number”機能をうまく使えば、何とかなりそうな気もします。

3) データベースをわかりやすくしたい

単なる連番で作られるような、人工的なキーよりも、より自然な「複合キー」の方が、理解しやすい、という場合があります。これはおそらく、エンドユーザが、「直接」データベースを見ることを想定してのことですね。

Martin Fowler氏の主張する、 「アプリケーション・データベース」 -データベースを単一のアプリケーションの「ストレージ」として考える-のようなものを想定すれば、こういった「わかりやすさ」は必要なくなるかもしれません。

もっとも、私の経験では、エンドユーザは「人工的なキー(の必要性)」というものを、意外に理解してくれます。あるいは、そんな「技術的なこと」には関心をもたないか、ですね。逆にプログラマの方が、こういったやり方に首をひねることが多いような気がします。おそらく、かって「階層型データベース」を使っていた経験などから、先入観を持ってしまっているのだろう、と推察しますけど。

---

Ruby On Railsでの、「全ての主キーを単一の自動連番とする」というプラクティスは、とてもシンプルで、望ましいやり方だと思いますね。「主キーの選定」は、間違えるとひどいことになりますけど、この方法なら、そういったことは起こりませんし。「主キーの選定」に頭を悩ます時間も節約できます。

私もデータベース設計では、つい複合キーを使いがちではあったのですが。最近は、可能な限り単一キーとする方が良いと考えています。こう考えるようになったのは、Railsの影響が大きいですね。

ちなみに、「T字形ER手法」でも、「主キー(「認知番号」)の複合構成は認めない」という記述があり、同じ考えを持っているようです。

---

 

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして Book データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

著者:佐藤 正美
販売元:ソフトリサーチセンター
Amazon.co.jpで詳細を確認する

|

« 「コメント率50%」の謎 | トップページ | ソフトウエアの設計は協業の基礎を作ること »

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« 「コメント率50%」の謎 | トップページ | ソフトウエアの設計は協業の基礎を作ること »