折角なので今考えていること

はてブで書いたことなんだけど、「エンティティ」+「ロール」+「ワークフロー」+「補助的な問い合わせ条件」っていうのをフレームワーク化できないかと思案中。これは、d:id:terazzo:20071113:1194974612で考えていた「リソース」+「権限認証」+「ワークフロー」で作るコミュニティ(orグループウェア)エンジンという考えにも繋がってくる。
Buriのいいと思うところは、ワークフローに関するフラグ管理をプログラム上で意識しなくて良いところ。DB設計としてのフラグがまずあるのではなく、ワークフローという目的がまずあり、その実現方法としてフラグがあるので、ワークフローさえ定義すれば個々のフラグを考慮する必要はないという素晴らしい発想の転換(だと思う。実はまだ使ったこと無いので……)
ワークフロー分岐用フラグ同じように、ほとんどのFKもプログラムから排除できるのではないかと思う。本当に実現したいのはエンティティ間の関連(オーナーシップなど)であって、FKというのはその実現手段でしかないのではないだろうか？ということはオーナーシップを記述するルール(とプログラムからルールを扱うAPI)さえあれば、FKを意識することなくプログラムを作成できるはずだ。
さらに進めれば、PK(主に代理キーの場合)もプログラムから排除できるのではないか。URLのように外部のAPIでインスタンスを特定するような場合、重要なのはそのURLでインスタンスが特定できることであり、どういう属性名でPKを保持しているかは二次的な問題だ。URL(パラメータ含む)と個々のインスタンスの間の相互のマッピングを自動化できれば、パラメータを取得してIDで検索して、というプログラムは書かなくて良くなる。他のエンティティのFKとなっている場合、上記のルールAPIで当て込んで取得できるので、やはりPKを意識する必要は無くなる。
この考え方は、RESTの接続性という考え方と相性が良いと思う。接続性があるということは、URLのフォーマットを意識しなくても良いということだ。(コレクションを取得する＝個々のインスタンス→URLマッピング、そのうちのひとつを操作する＝URL→インスタンスマッピング、ひとつのインスタンスに関連する他のエンティティのインスタンスを取得する＝URL→インスタンスマッピング+ルールAPI+インスタンス→URLマッピング、etc.) 不透明性というのが、つまりPK/FKをプログラムから排除する、ということにつながっている。
設定ファイルにID書いて管理する場合などはどうか。属性名はともかくIDは必要になるかも。
こうやって本人は新しいことを考えているつもりでも、アカデミー界／エンタープライズ界／オープンソース界のどこかに既に存在してそうだ。誰かポインターを下さい。

*追記

よく考えれば、(WebObjectsの)EOFってプログラム上はFKを意識する必要は無かった。EOModelerでリレーション作るときにポチポチ押すだけだもん。リレーションにインスタンスを追加したらキーをプロパゲートしてくれるし。この辺はHibernateでもできそう。でもできれば属性名まで勝手に作ってくれるようにしたい。