@DBFlute
ReplaceSchemaを使っている方、これから使う方に
ぜひとも使ってもらいたい機能です。(既存の機能です)
ReplaceSchemaのプロセスは以下のようになります：
1. Drop/Create Tables
2. Register test data
3. Check or Arrange
今回はまさしくこの「3」に着目します。
DBFluteクライアントの「./playsql/take-finally.sql」というファイルを
作成すると、このファイルのSQLが「3」のタイミングで呼び出されます。
普通にSQLを書けばなんでも動きます。ここでパスワードカラムに暗号を
掛けたり、アナライズしたり、とエクセルのテストデータ登録では
表現できないデータの微調整を行います。「Arrange」の部分です。
SQLに以下のようなコメント定義を付与すると、それはただ実行するSQL
ではなく、結果をAssertするSQLとなります。ここが「Check」です。
select count (*)
from MEMBER
where MEMBER_STATUS_CODE = 'FML'
and MEMBER_FORMALIZED_DATETIME is null
;
これは、「正式会員」なのに「正式会員になった日時」が存在しない
レコードが含まれていたら例外になります。
assertCountZeroは「件数が0であること」を意味します。
このように「RDBの機能で制約を掛けられない業務的な制約」を
徹底して検証します。これは実はプログラマだけでなく、
DBAにとってもとてもうれしい機能ではないでしょうか。
(いつもはがゆい思いをしてました。。。自分)
#
# MEMBER_FORMALIZED_DATETIMEをライフサイクルの違いということで
# one-to-oneの別テーブルにしてもよいですが、そうしたとしても
# 「正式会員」のときの「正式会員になった日時の関連レコード有無」を
# チェックした方が良いことには代わりはありません。
#
もう一つ以下のように書くことも可能です。
select local.MEMBER_ID, local.MEMBER_NAME
from MEMBER local
where local.MEMBER_STATUS_CODE = 'WDL'
and not exists (select sub.MEMBER_ID
from MEMBER_WITHDRAWAL sub
where sub.MEMBER_ID = local.MEMBER_ID
)
;
単純にSQLの結果が0件であることをAssertします。
使い分けはそのときSQLとしてどう書きやすいか次第で、
「df:assertCountZero」と「df:assertListZero」どちらを
使っても構いません。
あえて言うならassertListZeroの方が例外時に結果の不整合な
レコードのデータが表示されるでのその方が良いかもです。
たくさん作る必要はないです。
DBAがちょこっと気を利かせて、
「(設計中)あっ、ここはRDB的な制約が掛けられないや」
と思ったら作る。
プログラマがちょこっと気を利かせて、
「(開発中)あっ、ここは実際にはこうゆうデータ入ったら駄目だね」
と思ったら作る。
という感じです。ちょっとの検証SQLで効果は大きいと思います。
UTのテストが落ちたー、結合テストで不具合登録されたー
調べたら単にデータが悪かっただけだー
っていうときの「不具合登録」の作業も無駄ですし、
調べる作業も無駄です。そういうの出来る限り無くしましょう。
複数人でじゃんじゃん作成する場合は、
o take-finally-abc.sql
o take-finally-def.sql
o take-finally-ghi.sql
というようにファイルを分けることが可能ですので、
いい感じにファイルを分割してコンフリクト防止して下さい。
