jfluteの日記 このページをアンテナに追加

2008-07-09

DBFlute: AdditionalForeignKey

| 02:20 |

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

kkkk 2009/06/23 22:12 わたしもずっと(10年以上も)
FK使わない派(今までどの現場もそう)だったので
DBFluteは何故FK推奨なのかずっとモヤモヤしていたのですが..

なるほど!
このエントリ読んで考え方変えることにしました。

ありがとうございます。

jflutejflute 2009/06/23 22:20 おおお、kkさん、とてもうれしいコメントありがとうございます!!!
DBFluteは単にツールというだけでなく、こういった思想なども
伝えていくことができればと思っています。

nmasatomonmasatomo 2009/06/24 11:08 お久しぶりです。中村です。
某プロジェクトでは1000以上のテーブルがありますが、jfluteさんの話を元にFKを物理的に付与するようにしました。
結果、今のところ特に問題なく開発が進んでいて、第一弾がそろそろカットオーバーです。
結合テストや本番環境のDBAは私が見てるんですが、FKのおかげでマスタデータの不備が見つかったりして悪いどころかいい感じです。

jflutejflute 2009/06/25 21:25 おおおお、中村さん、おひさしぶりですー!
そして、とってもうれしいコメントありがとうございます。
1000以上のテーブル(すごい...)ですから効果もかなりあるんじゃないかと思います。
開発が進んでいるということを聞いてほっとしました。
まだまだこれから勝負所だと思いますがぜひぜひ頑張って下さい!