#xxfw

I want to say a little more about long-sql problem.Since I wrote it up in Japanese, I will paste it here.

長いSQL利用するメリットとデメリットが以下のものがあると考えられます。

メリット：

1. コード変更の影響範囲が小さい。 各プログラムの中に、同じ処理をやっているにもかかわらず、 利用するデータを毎回一番低い位置となる生のDBから取り出している。 一本のプログラムを修正しても、基本的には他のプログラムに影響しない。2. DB利用の効率がいい。 できるだけ多くの作業はひとつのSQLに書くと、 DBとのやり取りの時間が短くなって、コード全体的な効率がいい。

デメリット

1.開発は辛い。 DBの上に、抽象的なカプセル化したオブジェクトはないので、 どんなデータが必要になっても、一番下のDBからSQLで取得しないといけない。 そこで、ビジネスロジックにおいて、 各テープルの間の関連と関連の詳しい内容まですべて理解しないといけない。 仮にあるデータを取得するために、10個のテーブルをJOINする必要がある場合、 このデータを使う都度、この10個のテープルをJOINするSQLを書かなきゃいけない。 このような細かいビジネスロジックを理解する難しさと 大量の重複なソースコードを書く大変さは辛いと思います。2.メンテナンスはやりにくい。 「10個以上のテーブルで関連して、異なる目的のデータを一箇所で取得し、 それにデータの取得だけではなく、画面表示用のデータ構造まで作っている」 このような膨大な100行以上のSQLを細かく理解しないといけない。 これは長いSQLを利用する場合のメンテナンス作業の現実です。 このようなコードを理解するには、 システムの仕様をすべて理解できている方は少し時間がかかる、 SQLの理解能力があって、積極的にシステムの仕様を理解しようという方は結構時間掛かる、 そうでないと、ほぼ理解できないと思います。 言い換えると、仕事でなければ、100行以上のSQLを見ようとする人は多分いないと思います。 それに、もともと重複で書かれたSQLのコードはあちこち散在しているので、 一本のプログラムにSQLを修正して問題なしで終わったら、 今度メンテナンスする方は、 なんで同じデータなのに、全然異なる所から情報をとっているという疑問も生じやすい。

では、どうすればいいですか？と更に考えると、やはりDBの上に、ビジネスロジックをカプセル化した抽象的なものが必要だと思います。現在流行っているActiveRecordのようなORMのレベルに達しなくても、少なくとも最低限のオブジェクト指向の概念が必要と思います。

XXFWはJavaを利用して、MVC構造中のViewとControllerの部分を結構カプセル化されていて、便利になっていると考えています。

しかし、ビジネスロジックと一番関連の緊密のモデルの部分について、現実なロジックを解決するために出てきたオブジェクト指向の概念はほとんど利用していなくて、惜しいいと思います。

例で簡単に言いますと、ある受注の一番目の明細商品のお客様側の商品コードを取りたい時、

今のやり方だと、

select 商品対応表.お客様商品コードfrom 受注HDRinner join 受注DTL on 受注DTL.受注HDR番号 = 受注HDR.受注HDR番号inner join 関連会社 on 関連会社.関連会社コード = 受注HDR.関連会社コードleft outter join 商品対応表 on 商品対応表.商品コード = 受注DTL.商品コード and 商品対応表.関連会社番号 = 関連会社.関連会社番号where 受注HDR.受注HDR番号 = ?order by 受注DTL.行番号limit 1

オブジェクト指向の方法だと、

受注HDR.一番目の受注DTL.お客様商品コード

一目瞭然、SEにとっても、PGにとっても、後続のメンテナンスの方にとっても、オブジェクト指向の方法を使うほうがやりやすいでしょう。

では、オブジェクト指向の方法を使うと、影響範囲と実行効率の問題はどうなるでしょう？

1.影響範囲の問題 オブジェクト指向を利用すると、自動テストできるので、 更に、TDD(Test Driven Development)の手法を利用すれば、 影響範囲の問題がほぼなくなるだけではなく、 もっと効率的に（画面で確認するという伝統的なテスト手法はいらなくなる）、 もっと堅実のコードを作れると思います。2.実行効率の問題 DBにとって、一つ大きいSQLと分割したいくつかのSQLの実行時間の差異は非常に小さいので、 よぽど重い処理で無い限り、ユーザーはこの時間差を感じられないと思います。 その反面、メンテナンスの作業は何時間から何分間に変わるかもしれないです。 さらに、より新しいORMを利用すれば、 オブジェクト指向の方法も上記のような複雑のデータ取得に、 一つのSQLしか発行しないので、根本的に実行効率の問題解決できると思います。

プログラムを作り上げるという視点から見ると、KISS (Keep it simple and stupid) と DRY (Don’t repeat yourself)の考え方のもとで、オブジェクト指向を利用したほうが絶対開発は便利になる。

After starting using XXFW for nearly half a year,I finally can not help writing something down about how and why I hate using it.Actually there are many problems I met when I was using it,and some of them are not only related with XXFW,but have something to do with the whole development workflow of the company.

I can not describe them all in one post,but I will try to write from an objective point of view.

So today’s topic

one 100-line SQL VS hundred 1-line SQLs

From the view point of performance, this is out of question.Most time we will choose one 100-line SQL,because hundred 1-line SQLs' load burden will be much larger than one 100-line SQL.

What I want to discuss here is the maintenance part.“hundred 1-line SQLs” may be an exaggeration,but “one 100-line SQL” is not hard to imagine in XXFW at all.Actually, in the source code of XXFW systems,we can often find SQL sentences with 100~200 lines.

The problem is that it is really hard to read one SQL sentence,which has more than 100 lines,selects more than 50 columns by joining more than 20 tables,with different kinds of filtering conditions.Not to mention various structures and functions used in selecting columns.

In other words,this long SQL is written to do more than one thing by mixing lots of logic together.

In my opinion, because almost all XXFW systems are not so-large scale systems, user can feel no differences by changing one large SQL into several smaller SQLs.

But by doing this, the maintenance efficience will have a big boost,because every SQL will one do one thing with simple logic.And the whole source code will be much easier to understand.

The reason why many XXFW developers often write too-long SQLs is because of the structure of XXFW.It does not have the concept of MVC,so people can not encapsulate logic inside models.And without the encapsulation, the uint test or various auto test methods are far far away.