DBFluteは、DB上のFK制約の情報を元に
ConditionBeanでJOINできる関連を決定します。
FK制約が全く付与されていないDBでは、
別途「FK情報」をDBFluteに教えてあげる必要があります。
それが「AdditionalForeignKey」です。
{DBFluteクライアント}/dfprop/additionalForeignKeyMap.dfprop
ファイルを作成して、以下のように定義します。
map:{
; FK_MEMBER_MEMBER_STATUS = map:{
; localTableName = MEMBER ; foreignTableName = MEMBER_STATUS
; localColumnName = MEMBER_STATUS_CODE ; foreignColumnName = MEMBER_STATUS_CODE
}
; FK_MEMBER_MEMBER_ABC = map:{
; localTableName = MEMBER ; foreignTableName = MEMBER_ABC
; localColumnName = MEMBER_ABC_ID ; foreignColumnName = MEMBER_ABC_ID
}
}
このように定義することで、DBFluteに「疑似のFK制約」が
伝わり、その関連(FK)に関するメソッド等が生成されます。
【FK制約名】
ここで定義している「FK制約名」は、
ユニークであれば何でも構いません。
(現状内部管理のキーだけに利用していて
特に生成物として利用していない)
【カラムの省略】
localColumnNameとforeignColumnNameが同じカラム名であれば、
こられ属性を省略することができます。
以下のようになります。
(localTableNameとforeignTableNameだけを指定)
map:{
; FK_MEMBER_MEMBER_STATUS = map:{
; localTableName = MEMBER ; foreignTableName = MEMBER_STATUS
}
; FK_MEMBER_MEMBER_ABC = map:{
; localTableName = MEMBER ; foreignTableName = MEMBER_ABC
}
}
個人的には、FK制約は出来る限り付与することをお奨めします。
「FK制約は色々と煩雑になる」という意見もありますが、
自分の経験ではしっかりとした
「スキーマの管理」と「テストデータの管理」をしていれば、
ほとんどFK制約が煩雑だと思ったことはありません。
以下、自分が実際のプロジェクトで実践してきたやり方です。
＜スキーマの管理＞
ERDツール(EA)でスキーマを管理し、DDL(Create文)は自動生成。
DBFluteのReplaceSchemaを利用してそのDDLを実行するように。
JDBCのスキーマ情報からFKのDrop文とテーブルのDrop文を
自動生成して実行するため、
作り直しの時にもFK制約を意識する必要はありません。
(ReplaceSchemaを使わなくてもEAのようなERDツールは
FKのDrop文を生成することが可能ですし、データディクショナリ
をSelectしてDrop文を自前で簡単に生成することも可能です)
＜テストデータの管理＞
マスタ系など開発のためのベースとなるデータは、
DBAが最初から準備します。
(短期でもいいのでテストデータ作成専任の人がいるとなお良い)
DBFluteのReplaceSchemaでスキーマを作成する時点で、
それらデータも一緒に登録するようにします。
そうすることで、各ディベロッパーがテストデータを
投入する際にかなり楽になります。
他にも細かい要因がありますが、
要はやり方次第でどうにでもなるので、
それをやらずに「整合性の崩れたデータの入る危険性」を
発生させてしまうのはもったいないと考えます。
FK制約を付与しないというのは、
「開発者の都合で運用者の首を絞める」ことになりますし、
「開発者の都合でデータ不整合の危険性をお客様へ提供する」
ことにもなります。
【追記】
// その後のちょいエントリ - FK制約のススメ
http://d.hatena.ne.jp/jflute/20090623/1245767585
