InnerJoinAutoDetect

• 概要
  • 基本概念
• 判別ロジック
  • 構造的アプローチ
  • 検索条件アプローチ
  • 安全寄りのロジック
• 一律の設定
  • 1.0.3からはデフォルトで有効
  • 1.0.2以前：リリース前なら一律 @until 1.0.2
• 細かい仕様について
  • Union や SubQuery では
  • ネストしたリレーションでは
  • 1:必ず1リレーションでは
  • 内部結合したいのは主には検索条件アプローチ

概要

left outer join でも inner join でも結果が変わらない結合を自動で判別して、inner joinにします。

e.g. InnerJoinAutoDetect を使った conditionBean による検索 @DisplaySql
select dfloc.MEMBER_ID, dfloc.MEMBER_NAME, ...
  from MEMBER dfloc
    inner join MEMBER_STATUS dfrel_0 on ...
    left outer join MEMBER_SEcURITY dfrel_1 on ...
    left outer join MEMBER_SERVIcE dfrel_2 on ...
    inner join MEMBER_WITHDRAWAL dfrel_3 on ...
 where dfrel_3.WITHDRAWAL_DATETIME >= '2014-08-08'

基本概念

そもそも conditionBean は、外部結合(left outer join)的な挙動を基本にしています。 そこには明確なポリシーがあり、内部結合(inner join)はパフォーマンス考慮のための手段と捉えています。

InnerJoinAutoDetectは、手動の (Manual)InnerJoin とは別に、InnerJoin 可能な結合、つまり外部結合である必要のない外部結合を自動判別する機能です(@since 0.9.8.8)。

判別ロジック

大きく二つのアプローチがあります。

構造的アプローチ

NotNullのカラムでFK制約のあるリレーション

検索条件アプローチ

where句で絞り込み条件として利用されているリレーション

ポイントとしては、相手(関連テーブル)側のデータが存在しないレコードが、確実に検索対象から外れてもいいのかどうかを判断することです。

構造的アプローチ

NotNullのカラムでFK制約のあるリレーションは、InlineView や Onclause で結合する前に絞り込みが発生していない限りは、相手側のデータは必ず存在します。

e.g. InnerJoinAutoDetect 構造的アプローチ @DisplaySql
select dfloc.MEMBER_ID, dfloc.MEMBER_NAME, ...
  from MEMBER dfloc
    inner join MEMBER_STATUS dfrel_0 on ...

ただし、AdditionalForeignKey (疑似FK) によるリレーションは対象外です。DBMS側でFK制約がないのであれば、不整合なリレーションが発生する可能性があるからです。 物理的なFK制約が存在していることが前提です。

検索条件アプローチ

(一部例外を除き) 相手側のカラムで where 句で絞り込み条件が指定されていれば、相手側のデータは必ず存在します。

e.g. InnerJoinAutoDetect 検索条件アプローチ @DisplaySql
select dfloc.MEMBER_ID, dfloc.MEMBER_NAME, ...
  from MEMBER dfloc
    left outer join MEMBER_SEcURITY dfrel_1 on ...
    left outer join MEMBER_SERVIcE dfrel_2 on ...
    inner join MEMBER_WITHDRAWAL dfrel_3 on ...
 where dfrel_3.WITHDRAWAL_DATETIME >= '2014-08-08'

絞り込み条件を指定していれば、自然と null のレコードは除外されます。 つまり、結合して相手が存在しないレコードは絞り込まれるので、inner join でも結果は変わりません。

ただし、その条件が、IsNull や coalesce() など null のデータを対象にする条件の場合は、判断の要素には含まれません。 また、OrScopeQueryで指定された絞り込み条件は、確実に相手側が存在するレコードだけを対象にすることが保証されないため、判断の要素には含まれません。 さらに、InlineView や Onclause の絞り込み条件は判断の要素には含まれません。

安全寄りのロジック

その他、AdditionalForeignKey の OverRelation を利用しているリレーションなど、判断がとても複雑になるケースにおいては、判断を諦めて inner join にはしません。 100% inner join にしてもOK、という判断が下せない限りは、left outer join を保ちます。

一律の設定

1.0.3からはデフォルトで、全ての conditionBean が InnerJoinAutoDetect になっています。

それ以前のバージョンでは littleAdjustmentMap.dfprop の isInnerJoinAutoDetect を true にすることで、全ての conditionBean で InnerJoinAutoDetect を有効にすることができます。

細かい仕様について

Union や SubQuery では

Union や SubQuery などの conditionBean でも InnerJoinAutoDetect になります。 ただし、リレーションの判別処理はそれぞれ独立しているため、例えばメインの select で inner join になったリレーションも、Union 側の select ではそのようになるとは限りません。

ネストしたリレーションでは

ネストしたリレーションが "検索条件アプローチ" で内部結合対象となった場合、そのリレーションを辿る途中のリレーションも内部結合となります。 これは、SQLの文法的にそのように判断しても問題ないためです。 (A, B, c と結合していて、c のカラムで絞り込みをしていれば A と B も内部結合)

ただし、ネストしたリレーションが "構造的アプローチ" で内部結合対象であっても、そこまで辿る途中のリレーションが一つでも外部結合であれば、そのリレーションは特に内部結合の候補にはなりませんし、 そこまで辿る途中のリレーションはそのままです。これは、SQL文法的にこのケースで内部結合にすると、基点テーブルの件数が変わってしまうためです。 (A, B, c と結合していて、B と c が構造的に内部結合対象であっても、A と B が外部結合であれば A, B, c 全て外部結合)

1:必ず1リレーションでは

例えば会員と会員セキュリティのような、絶対に相手が存在する 1:必ず1 の関係であっても、これは構造的アプローチによる内部結合の候補にはなりません。 相手が絶対に存在するカージナリティかどうかというのは、DBMSの制約ではなく業務的な制約なので、スキーマのメタデータには含まれません。 つまり、DBFluteとしては、1:必ず1なのかどうかが判断できないのです。