@DBFlute http://d.hatena.ne.jp/r_ikeda/20090512/query とても良い記事なので紹介させて頂きます。 確かにSQLは書く時、Selectはとりあえず書いても、 Select句の内容は「*」とか「...」とか保留して、 From句やWhere句書いてからSelect句をきっちり書く ってのが多いですね。 1. どのテーブルを基点にするか 2. どの関連のテーブルを取得するか 3. どのような条件で抽出したいか と記事にありますが、個人的にも主張したいのが「1」です。 SQLの相談を受けることが立場的に多いのですが、 意外にこれが抜けてる状態で質問されることが多いです。 「何を取得したいの？(何を基点とするの？)」 が即答できない場合は、結果セットのレコード単位が はっきりしていない可能性があります。 (レコード単位というかレコード粒度というか、要は SQLの結果セットは何でユニーク？ってところですね。 自分は勝手ながら「レコード単位」と呼んでいます) １レコード１会員なのか、１レコード１購入なのか、 はたまた「会員 left outer join 購入」 (基本的に購入単位だが購入の無い会員も含む)なのか、 これがはっきりしないと先に進みません。 なので「何を取得したいの？(何を基点とするの？)」が大事。
なによりもうれしいのが、ConditionBeanの目的指向を ヒントにして頂いているところです。 ConditionBeanはDBアクセスの組立てAPIなので、From句から というよりは、setupSelect()やquery()で必要なものを CB内部で自動で判断してFrom句を構成する形になりますが、 目的指向の手順的な概念は紹介されている手法と直結します。 DBFluteはプロジェクトでツールとして役立てるだけでなく、 DBFluteを学ぶことで「DBアクセス」というものを学べれば と考えています。ConditionBeanの目的指向はまさに ツールとしての利便性とその概念が直結しているところです。 また、DBアクセスのエッセンスをDBFluteの機能という 明確で具体的な概念と関連づけることで、非常にその概念が 覚えやすくなるとも考えています。 「関連テーブル(だけ)を絞り込む{OnClause}」 「子テーブルの条件で絞り込む{ExistsSubQuery}」 「子テーブルの導出カラムを取得する{(Specify)DerivedReferrer}」 など、目的をそのまま機能として命名することで、 曖昧な概念を明確に捉えることができると考えています。 ConditionBeanを極めた人は、ベタッとSQLを書くときも ポイントをかなり構造的に押さえられるようになると考えています。
