A meta data table structure Force.com is using

InfoQ に salesforce.com の Chief Software Architect, Craig Weissman が Force.com の内部設計を語るプレゼンテーション InfoQ: The Internal Design of Force.com’s Multi-Tenant Architecture が上がってました。

こういう巨大なサービスの内部構造には興味があるので見てみました(英語をほとんど聴き取れませんでしたが)。Force.com - Multitenant Architecture Under the Covers « Blog - Dayspring Web Design and Development にも第三者による要約があります。

全体の指針として、
* １つのバージョンだけで顧客毎のカスタマイズはしない
* 開発者は現在のバージョンと次のバージョンだけの保守で済む
* ソーシャル系サービスと違い、会社などの組織単位でリレーションを分離できるので、 OrgID のハッシュでテーブルを partition

とくに興味があったのはユーザー定義のメタデータをどうやって保持しているかで、
* オーバーヘッドが大きいので DDLを使わない(動的に CREATE/ALTER/DROP TABLE しない)
* 自由度の高いピボットテーブル? でメタデータを定義、保持
* 数値や日付などのデータも文字列カラムで保持

具体的には、プレゼンテーションの 15:00 前後のスライドで解説していますが、Fields, Objects, Data の３つのテーブルを使っています。

ちゃんと理解してるか自信ないんですけど、たとえば、

Person:
  Name: Hiroshi Saito
  BirthDate: 1973-09-17

という構造をつくる場合、

Objeject:
  ObjID: 1
  ObjName: Person

Field:
  FieldID: 1
  ObjID: 1
  FieldName: Name
  DataType: String
  FieldNum: 0

Field:
  FieldID: 1
  ObjID: 1
  FieldName: BirthDate
  DataType: Date
  FieldNum: 1

Data:
  GUID: 1619c672-71d2-11de-8643-e784bb274b72
  ObjID: 1
  Name: ???
  Value0: Hiroshi Saito
  Value1: 1973-09-17

Person は ObjID=1 とわかっていれば、 Person は以下のクエリで検索できますね。

SELECT Value0 AS Name, Value1 AS BirthDate FROM Data WHERE ObjID = 1;

Index のあたりの話などは理解してませんが、 SalesForce が実際に運用しているデータ構造ならば自分で思いついたのよりまともなハズなので、次回、ユーザー定義データを保存する必要がある場合はこの方法でやってみようかと思います。