COBOLerからの脱却２ - SQLer 生島勘富のブログ

　ウォーターフォールのままでも切り口を変えればシステム開発は大きく変わる。アジャイル開発にも移行できます。

　　　　　　　　　　↓

　逆に、現状のままでアジャイル開発に移行すれば、大きな規模の案件ではカウボーイコーディングにしかならないです。ウォーターフォールで設計に時間を掛けても出来ないものが、アジャイル開発にすれば巧くいくなんてことは夢のような話でね。そんな夢のような話は実現しません。

１．初期のRDBMSを使ったシステム。

　初期の頃は、SQLが良く理解されず、こんな風に使われていました。

　ホスト言語というのはSQLを使う側の言語のことで、オブジェクト指向言語に限りません。COBOLになっても、RPG になってもPL/1になってもいいのです。DBはOracleでも、SQLServerでも、DB2でも、PostgreSQLでもかまわない。ホスト言語はどんな言語でもよいのですけれど、他の言語から見て、SQLは異物以外の何物でもありません。

２．現在のシステム。

　これはいくら何でもまずいと言うことで、O/Rマッパーや、LINQなどなどでラップしました。

　こんな感じになっています。で、ラップの仕方がいいとか、悪いとか、そんな議論が行われていますが、その議論自体が馬鹿げている。無駄以外の何物でもない。と言ってるわけです。

　なぜ、異物を内包し続けるのか？

　最初の段階で、当時は、ほぼ業界としてSQLが分かる人がいないまま走ってしまったのですけど、それをそのまま発展させて現状に至っている。

３．最初からこうしていれば……。

　真っ当に考えれば、こんな風になっていた訳です。これを発展させていれば、普通にこうなっているでしょう。

４．ストアドプロシージャでラップ。

　どこまで行っても、スタートラインでボタンを掛け違えたまんま、何年も何年も無駄なことをやってきているわけです。スタートラインでボタンを掛け違えているのですから、スタートラインまで戻らないと行けない。戻らないで、ラップするものをどんなにがんばって作っても、１．２．は

　「アルゴリズムのある言語」 → 「アルゴリズムのない言語」 → 「アルゴリズムの自動生成」

　これでは「アルゴリズムのない言語」挟む意味がないのでしょう。

　この構造ではどのぐらいまでSQLで処理しているかは、会社、プロジェクト、担当者の考え方によってまちまちです。粒度も合わないし、実に中途半端です。

分けれたら。

　以前、複雑なSQLをデチューンしていくというのを書きました。

　■１.OLAP関数を使って一括処理するパターン
　■２.誤差配賦額をファンクションを使って計算するパターン
　■３.誤差配賦額をファンクション内でループして計算するパターン
　■４.ワークテーブル（ループ）を用いてストアドプロシージャ内で計算するパターン
　■５.GROUP BYを使わない完全にループで計算するパターン（未実装）

　アルゴリズムがある言語で考えたら、■５ → ■４ → ■３ → ■２ → ■１の順で進まざるを得ない。しかし、バラしたものをまとめていくのは非常に難しく、■５ → ■４でもかなり高いハードルです。それができるのが「SQLができる」ってことになっていたり（苦笑）。

　また、例ではストアドプロシージャにしていますがストアドプロシージャを嫌がる人が多い。嫌がる人で■１まで行ける人はまず居ないから、■２、■３、■４、■５で使われているSQLをホスト言語（母言語）から実行することになるでしょう。そうなっていたら、ホスト言語（母言語）とSQLは切り離せないものになってしまいます。

　しかし、ストアドプロシージャにしていれば、ユーザインターフェース側は、以下の様なスタブで開発、テストできます。

-- ダミービューの作成
CREATE VIEW xTEST_FUNC_VIEW AS 
SELECT 
　　900001 AS 請求書NO
　　, 1000001 AS 行NO
　　, 1 AS 納品書NO
　　, TO_DATE('20100617', 'YYYYMMDD') AS 売上日
　　, 500001 AS 得意先ID
　　, 2 AS 丸め単位
　　, 12345678 AS 商品ID
　　, 'A' AS 商品区分
　　, 255 AS 単価
　　, 10 AS 数量
　　, 127 AS 消費税 
-- FROM DUAL Oracleの場合必要
UNION ALL 
SELECT 
　　900001
　　, 1000001
　　, 2
　　, TO_DATE('20100617', 'YYYYMMDD')
　　, 500001
　　, 2
　　, 12345679
　　, 'B'
　　, 355
　　, 20
　　, 355 
-- FROM DUAL Oracleの場合必要

　　CREATE PROCEDURE  TEST_PROC
　　　　(
　　　　@pFrom datetime　　-- 期間開始日
　　　　, @pTo datetime　　-- 期間終了日
　　)
　　AS

　　　　SET NOCOUNT ON;

　　　　　　-- 本番時は以下のSQLを修正し、このコメントを削除する。
　　　　　　SELECT * 
　　　　　　FROM xTEST_PROC_VIEW 
　　　　　　WHERE 
　　　　　　　　1 = 1
　　　　　　;

GO

　ユーザインターフェース側の言語に一切関わりなく開発が可能です。

　SQLの考え方では、■１ → ■２ → ■３ → ■４ → ■５の順で考えて行きますが、ユーザインターフェース側の言語に迷惑を掛けずに修正できますから、スタートは■５でもかまわない。SQL側の担当者はSQLを徹底的に訓練するのですから、■１から考えれるようになるのにそう時間は掛からないはずです。

　ユーザインターフェース側とSQLを同じ人が担当する。担当せざるを得ないからどっちも中途半端になる。

　専門性を持った分業体制に出来れば、工数も、納期も、パフォーマンスも好転しますし、もっとリッチなユーザインターフェースになっていきます。それでも、ユーザインターフェース側の言語の仕事は確実に減るでしょう。技術者としてどちらを選ぶべきでしょうかね。

中途半端になるのが正しいと思う人。
中途半端になるのがおかしいと思う人。
中途半端はおかしいと訴える人。

　正しいと思う人はイタイな〜。少なくとも私はそういう人を技術者とは認めない。