Skip to end of metadata
Go to start of metadata

ER図とSQLの二重管理をやめよう

これは、そのまんまです。

大抵のWebアプリは、DBが無いと動きません。つまり、そのWebアプリ用のDB初期化SQLがあるはずです。そこにはCREATE TABLEを中心に色々なSQLがズラッと並んでいる。

だがしかし。SQLって読みづらいんですよね。IDEにリファクタリング機能とかもないし…

1

しかし、便利なアイテムとしてER図ってのがあって、これは人間としては直感的で分かりやすい表現形式です。業務ではドキュメントとしてメンテナンスしなきゃいけない対象だったりすることも多いものです。一般的なER図エディタはそのER図から上記のSQLファイルを生成できたりします。もちろんJiemamyでもできます。しかし、ER図上でDBを更新するたびに、そのER図エディタからSQLのエクスポートして、それをDBに流さなければなりません。

そんなわけで、SVNリポジトリには「ER図データファイル」と、それをエクスポートした「SQLファイル」の両者がコミットされたりする。さてさて、DRY

2

的にいかがなものか。1つの情報(データとかロジック)は1箇所に記録すべきであって、複数箇所に冗長に記録すべきではない、という考え方です

3

ER図とSQLファイルは、表現方法は違うけど、どちらも「DBの構造をあらわす情報」であって、二重に管理すべきではありません。二重管理はどんな混乱をもたらすか、その可能性には例えばこんなものが。どちらもありがちで、そして気づきにくいトラブルです。

  • ER図は更新したけど、SQLエクスポートを忘れたままコミットした
  • 新メンバーがER図の存在に気づかず、SQLを直接編集してコミットした

じゃーどうしたらいいんだ。まぁ「めんどくさくても毎回ER図エディタを起動する」か「DRY妥協」かどっちかですかね。

ここで地豆登場

簡単な事です。ER図データファイルをSQLに変換するロジックをどこからでも呼び出せるようにしちゃえばいいじゃないですか。そしたらわざわざER図エディタを立ち上げなくても済みます。

DB環境を整えるのもビルドプロセスの一つだよね、という意識でJiemamy Projectでは、この「Jiemamyモデルファイル→SQLファイル」への変換を提供するMavenのプラグインを提供

4

しています。これがあれば、「DBの構造をあらわす情報」はJiemamyモデルファイルだけで済み、DRY原則に従うことができます。

補足

ちなみに、Jiemamyモデルファイルを単純にSQLに変換するだけじゃなくて、他の変換も行いたい、変換だけじゃなくてモデル情報のコントロールも行いたい、なんて時には、Jiemamyのデータモデルを操作するAPI、「Jiemamy API」があります。イントロダクションで紹介したもう一つの視点です。まぁこれに関して詳しくはまた別の機会に。


Footnotes
Ref Notes
1 私の知る限り、ありません。カラム名変えたらINSERT文のカラム名も変わってくれるようなSQLエディタってありますかね。
2 Don't Repeat Yourself
3 参考: http://ja.wikipedia.org/wiki/Don%27t_repeat_yourself
4 今後、Mavenだけでなく、Antタスクにも対応する予定です。
Labels
  • None