データベース設計における主キーの考え方 - アラッポ・カーロの備忘録

本日、職場で行なわれた、DB設計に関する議論に関してまとまりなく記述します。
私の立ち位置としては、RDB嫌いでして、システムが複雑化するのは、RDBが諸悪の根源？と思っています。オブジェクト指向のパラダイムを理解しにくくするもののひとつに、RDBがあります。RDBを利用するかぎり、せっかく美しく正規化をしてモデリングしてテーブル設計を行っても正規化崩しをする必要が出てきてしまいます。

RDBの設計教科書にも正規化崩しは手順として出てきます。これは、問題領域（ドメイン）をわかりやすくモデリングするのには、あってはならないことです。RDBの支配する世界では、従業員番号や商品番号を「識別コード」として、それを主キーとします。この主キーを手がかりにする方法はテーブルを設計するのには利用できても、そこで表したい知識を概念化して変更の少ない普遍的なソフトウェア構造を作るのには弊害となります。
たとえば、識別コードをテーブルの主キーにすると、変更履歴をうまく扱えない。たとえば、商品番号を主キーとする商品テーブルの場合、商品Aの3月までの価格が1,000円で4月に価格改定があって1,200円になった場合、この変更を記録する場合、3月以前のレコードと4月以降のレコードが同時に存在することになります。
主キーはユニークでなければならないので商品番号は主キーにできません。商品番号を変更日を複合キーとすればユニーク性は保証されますが、検索方法が面倒になります。このような問題はみなさんも経験があるのではないでしょうか？また、識別コードに意味を持たせた設計であるために桁が足りなくなるといった問題もよく起こります。これらは、本来属性として扱うべき内容を名前に押し込めようとしているからです。UMLモデリングの本質より

全体の設計をRDBに頼りすぎないほうが良いように最近思っています。検索のロジックや集計をRDBの機能に頼り過ぎないほうが良いこともあります。RDBのテーブル設計を単純化してアプリケーションでRDBのインデックに相当する部分を実装するのです。うまく説明ができませんがこの手法は結構いけそうな予感がします。
複雑な業務ロジックが絡む検索などはJAVAのHashTableなどを利用してアプリケーションレベルでインデックスを持つのです。メモリ展開なので高速です。もちろん何万件もの中からの検索などには向きませんが・・・設計しだいでしょうか？
J2EEでいえば、CMP Entity Bean とかですか？
http://www.martinfowler.com/eaaCatalog/tableDataGateway.html
http://www.toshiba.co.jp/tech/review/2002/04/57_04pdf/sinseiki.pdf
http://www.precisejava.com/javaperf/j2ee/Patterns.htm#Patterns103
よのなか困ってる人が増えてきてRDBが終焉を迎える日も近いのでは？

また、「主キーが複合キー」に関しては、次のようなこともあります。
たとえば、扱う情報が、基本的にはカード会員番号毎の利用明細に関連する情報であるシステムの場合に通常、静的な側面のモデルでは、カード会員番号がキーとなるモデルをもとにテーブル設計するわけですが、そこに、時系列の考えや、利用期間による会員の分割管理が必要になると、下記のような複合のキーを持つテーブルが必要になり、検索方法が面倒になります。（カード会員番号＋決済日＋転入日）サロゲート（会員番号とは関係のないユニークな代理のコード）を利用すれば問題は解決されるが、そのかわり、会員番号が主キーであるという主張が撤回されてしまいます。
この辺に、RDB機能に頼りきったアプリケーション構築に限界を感じています。とはいえ、完全にOOベース設計として、DBを単なるデータ永続化のツールと考えたり、OODBを利用したり、DBのアクセスに対してアプリケーション・ファサードを構築できれば良いのですが。
従来の設計手法においては、アクセスのパフォーマンスおよびSQL文作成単純化の観点においてどのような判断基準で設計を行なうのが良いのでしょうか？個人的にはサロゲートの利用が気に入っていますがどうでしょうか？DBのテーブルを単体で評価したとき違和感がありますかね。でも、複合キーは、結合やその他SQL操作が非常に煩雑になってしまいバグの元であるようにも思えます。
以上のような考えで頭の中がもやもやしていたのですが、下記の記事を読んで考えがすっきりしました。コード体系ってUIなんですね。