@DBFlute, Java, 複合主キー, 複合PK, 複合外部キー, 複合FK DBFluteは「複合主キーのテーブル」では、 o Behavior.LoadReferrer o Behavior.QueryUpdate o Behavior.QueryDelete o ConditionBean.ExistsSubQuery など、サブクエリ系の機能が利用できません。 なので、サロゲートキーを利用して複合主キーを 無くすのがお奨めです。 追記(2010/07/29)： 幾つかの機能はサポートされるようになりました。 http://d.hatena.ne.jp/jflute/20090714/1247566634 ちなみにこれは、大抵の他のツールでも似たような制限が ある場合もありますし、純粋にJOIN句書くのが大変だし、 IN句のSubQuery(DBFlute的にはInScopeSubQuery)が どうにもならなかったりと、周辺のものとことごとく 相性が良くありません。なので、DBFluteを使うか使わないかは あまり関係なく設計時に考慮することが良いと考えています。 但し、絶対に忘れてはならないのが、 「サロゲートキー付けたら、元のビジネスキーにユニーク制約を」 結構、色んなシステムのDBを見る機会がありますが、 (DBFluteを使ってるシステムに限らず) 意外に多いのが上記のユニーク制約の付け忘れです。 付け忘れというかそういう概念すら無い場合もあったりします。 「なんでもかんでもとにかくID付ければ」というのだけが頭にあって、 それ以上のことが考えられていないケースがあります。 サロゲートキーを付けるだけでは、ビジネス的な制約が無くなってしまい、 周辺のものと相性は良くなりますが、データ不整合のゴールキーパーが いなくなってしまいます。IDを付けることに反対ではないですが、 安全性を(わざわざ)失って開発してる様をみてると悲しくなります。 (結合テストとかでSQLが落ちて、必死にデバッグして 結局テストデータの不整合が原因だった、って。。。) なので、サロゲートキーはお奨めですが、そのときユニーク制約も 一緒に付けることがお奨め(というか個人的には必須)です。
