DBFluteの区分値機能は、
テーブル区分値と暗黙の区分値の両方をサポートしています。
区分値 (Classification) | DBFlute
さて、そもそもテーブル区分値と暗黙の区分値どっちがいいの？
そんな話が現場で出ました。
まあ、単純に考えれば「テーブル区分値」です。
論理的にはテーブル区分値
一番の理由は、ドキュメントの通り、
FK制約の恩恵を受けられること。単純ですが大きい。
DBFluteを使うと isCheckImplicitSet で、
アプリ上でチェックを入れることができます。
すると、イーヴンイーヴン？
まあ、差は縮まりますが、普通に手で更新や登録するときとか、
別のツールとかで触るときの安心感がやっぱり違います。
もう一つ。
クエリーの表現力が変わります。
表示順カラムでソートしたり、その他要素で絞り込んだり、
これは区分値がしっかりDB上に存在しなければできません。
また、ConditionBean において、
DerivedReferrer 使って区分値ごとの集計したり、
ColumnQuery と合わせて兄弟レコードの値で絞り込んだり、
区分値がしっかりテーブルという概念として存在していることで、
表現できるSQLの幅が広がります。
暗黙の区分値は、暗黙という名前だけあって、
何もないんだから、もうそれ以上 DBFlute は何もできないんですね。
(というか、SQL自体がそれに対して何もできない)
実際に使う場面はそんなには多くはありませんが、あるとうれしいもの。
さらにもう一つ。
そこまで大きな話ではありませんが、ERD上に明示的に存在することで、
区分値に対するリレーションがとてもわかりやすくなります。
「えー、べつに」と思われるかもしれませんが、
そこは単なる価値観の違いかもしれませんが、
区分値はアプリにとってとても大事な存在だと考えているのです。
区分値によって、レコードの振る舞いが変わるから。
特にディベロッパーにとっては重大な要素なのです。
ということで、その三つのポイントから、
s「論理的」には「テーブル区分値」がオススメです。
物理的には...？
さて、現場ではちょっと違った要素が入り込んできました。
物理的には？という要素。
テーブル区分値は作れば作るだけJavaのクラスが生成されます。
それがゆえに、Java の Permanent 領域を使います。
大きなシステムになると、テーブル区分値の数も膨大でしょう。
他の要因もあるでしょうが、テーブル区分値のクラスも
それに貢献してしまっているでしょう。
それがゆえに、あまりアプリでは重要ではない、
例えばレポート用のSQLとかでしか利用されない区分値などは、
暗黙の区分値にしておくというのも一つの手でしょう。
ただ、一つ注意してもらいたいのは、
その基準がぐだぐだになってしまうと、
しばらく時間が経ったのち、ちぐはぐさが露呈します。
新しくメンテナンスする人は迷うでしょう。
「テーブル区分値のメリットを享受したい！」
というときに限って、うまく享受できないみたいな
ことも起こりえるでしょう。
テーブル区分値が良いと言っても極端な話、
決定的なものではありません。
どっちにしたってシステムは作れます。
ただ、どちらかというとテーブル区分値にしていった方がいいねと。
恐らく一番よくないのは「中途半端」なこと。
DBFluteで改善できるようにしてみました。
1.0.5Bからは、
テーブル区分値のBehaviorの生成を抑制するオプションがあります。
テーブル区分値を基点にDBアクセスをすることは少ないので、
コンパイルエラーにならなければ抑制してしまってよいでしょう。
Behaviorが生成されるクラスの中で一番でかいやつです。
効果はとても高いと思います。
1.0.5G (6/1パッチ) からは、
NestSelectSetupper (Nss) が、不要なときは生成されなくなります。
例えば、一つもFKを持っていないテーブルのときとか。
テーブル区分値はリレーションの先っぽなので、
ほとんどの場合は Nss が不要でしょう。
クラス自体は小さいですが、テーブル区分値が100個されば、
100クラス消えるのでわりと大きいでしょう。
また、同じく1.0.5G (6/1パッチ) からは、
dfpropで徹底したテーブル区分値スリム化を実現できます。
e.g. テーブル区分値のスーパースリム化 | DBFlute
InlineViewを抑制すると、CIQクラスも生成されなくなりますので、
Nssと合わせると、かなりのクラスが抑制されます。
CQなどもかなりすっからかんになるので、軽いクラスとなります。
迷うくらいなら DBFlute を直しますよ
そして、忘れてはいけないのは、
アプリ変え易く、DBは変え難いもの
というセオリー。
アプリを直したり改善したりするのはわりと簡単です。
DBを直すというのはそれに比べれば腰が重いもの。
それは区分値の話に限らず、どこでもそう。
フレームワークだって、DBに比べれば直し易いものです。
Java8だとPermanent領域の扱いも変わっているようですし、
物理的な問題は別の要因でさっくり解決することもあります。
そう、だから現場で迷うくらいなら DBFlute を直しますよ。
もっと早く改善していれば、と申し訳ない気持ちありつつ、
そーとースリムにしたので、そんなに気にする必要はないくらいかと。
それでも気にしなければならないくらい切羽詰まってるなら、
もっと他のクラスも気にしないといけないのではないかなと思いますし、
そのときはまた DBFlute を改善します。(まだできることもあるかなと)
DB、というか、テーブル自体は何も悪くない訳ですから。
本来は、迷って議論するほどの問題ではないはずです。
テーブル区分値と暗黙の区分値の基準をしっかりと明確にし、
今の人も新しい人も迷わない「見通しのよいシステム」を
構築していってほしいと願います。
