the N+1 Schema Problem

Lambda the Ultimate の以下の記事より．

Why Normalization Failed to Become the Ultimate Guide for Database Designers? , Lambda the Ultimate

以下，引用．日本語は拙訳．

In my experience, nothing seems to effect lines of code in an enterprise system more than schema design, both in the data layer and logic layer, and often an inverse relationship exists between the two; hence the use of object-relational mapping layers to consolidate inevitable problems where there will be The Many Forms of a Single Fact (Kent, 1988).

私の経験上，データベース・スキーマ設計以上に，企業システムのコード量を左右するものはないと思える．これは，データ層，ロジック層の両方についていえる．また，しばしば両者の関係は逆転する．そして，object-relational マッピング層（ O/R マッピング）の使用は， 単一事実の多くの形態の存在 (Kent, 1988) という，避けようのない問題を，確実にもたらすことになるだろう．

Mapping stabilizes the problem domain by labeling correspondances between all the possible unique structures.

O/R マッピングは，可能でありユニークな，あらゆるデータ構造群の関係，とされる問題領域を保ち続ける．¹

I refer to this among friends and coworkers as the N+1 Schema Problem, as there is generally 1 schema thought to be canonical, either extensionally or intensionally, and N other versions of that schema.

私と友人，同僚との間では，この問題を， the N+1 Schema Problem として言及している．すなわち，一般的に，数学的公理に則った（ canonical ）と考えられる， 1 つのスキーマがあるとき， - それが外延的であるか内包的であるかを問わず - 別にそのスキーマの N 個のバージョンが存在する．

・・・

O/R マッピングというのは，クラスのフィールドに対して，テーブル，およびクエリ結果のカラム（ relation の attribute ）を対応させるのが一般的だと思います．

O/R マッピングがこのように行なわれるとしますと，アプリケーション側からデータベースをみたとき，データベースは，クエリによって，新しいデータタイプを実行時に生み出していることになるわけでして．極端な話， SELECT 文のカラムリストが一つ違うだけで，異なるデータタイプが生み出されることになるんですよね．

マッピングがコンパイル時に行なわれるのだとすると，データベース・スキーマが持っている， relation データタイプの情報を，コンパイル前に，アプリケーション側のプログラミング言語にコピーすることになります．そして，そのコピーは大抵，改変を伴って行なわれます．つまり，アプリケーションごとに，データベース・データタイプの別バージョンコピーを持つことになります．

これが， object-relational 間のギャップがもたらす，より大きな，そして深刻な問題ではないかと考えます．

---

1. データベースの用語では，データ統合 data integration の問題．プログラミングの用語では， DRY (Don't repeat yourself )原則の問題かと思う．