[seasar-dotnet:1865] Re: [DBFlute.NET]業務的one-to-oneな条件に他テーブルのカラム値指定
kubo
[E-MAIL ADDRESS DELETED]
2010年 10月 11日 (月) 22:37:42 JST
久保(jflute)です。
fpさん、もうちょっとアドバイス頂ければと思います。
定義した業務的one-to-oneの foreignTable を経由した
さらなる foreignTable のカラムを fixedCondition に
利用するパターンですが、二つの left outer join が、
互いに参照し合うのでSQL的に動作するのかどうか、
ちょっと疑問に思っています。
local = MEMBER
foreign = MEMBER_LOGIN (業務的one-to-one)
foreignのforeign = MEMBER_STATUS (LOGIN経由)
select ...
from member dflocal
left outer join MEMBER_STATUS dfrelation_4_1
on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
dfrelation_4_1.MEMBER_STATUS_CODE
left outer join MEMBER_LOGIN dfrelation_4
on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
and dfrelation_4_1.DISPLAY_ORDER = 2
だと、MEMBER_STATUS の left outer join が先に来て、
dfrelation_4 が(まだ)解決できません。順番を逆にしても：
select ...
from member dflocal
left outer join MEMBER_LOGIN dfrelation_4
on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
and dfrelation_4_1.DISPLAY_ORDER = 2
left outer join MEMBER_STATUS dfrelation_4_1
on dfrelation_4.LOGIN_MEMBER_STATUS_CODE =
dfrelation_4_1.MEMBER_STATUS_CODE
今度は、MEMBER_LOGIN の on 句で、
dfrelation_4_1 が解決できません。
MySQLとPostgreSQLで実際に試してエラーになりました。
頭の中でいけるかなぁと勝手に思っていはいたのですが、
いざやってみると確かに...。
ちょっと自分が勘違いしているかもしれません。
fpさんのところで実業務で想定しているパターンを
もう少し情報頂けないでしょうか？
(どういうSQLを想定されていますでしょうか！？)
#
# 以下のようにすれば、いけそうですが、
# 同名カラムをどう解決したものかってとこですね...
#
select *
from member dflocal
left outer join
(select *
from MEMBER_LOGIN
left outer join MEMBER_STATUS dfrelation_4_1
on MEMBER_LOGIN.LOGIN_MEMBER_STATUS_CODE =
dfrelation_4_1.MEMBER_STATUS_CODE
) dfrelation_4
on dflocal.MEMBER_ID = dfrelation_4.MEMBER_ID
and dfrelation_4.DISPLAY_ORDER = 2
2010/10/11 fp <[E-MAIL ADDRESS DELETED]>:
> fpです。
>
> ありがとうございます。
>
> 申し訳ありませんが、宜しくお願いします。
>
> (2010/10/11 18:46), kubo wrote:
>> 久保(jflute)です。
>>
>>> 当方のプロジェクトでは、話に出た全パターン当てはまります。
>> なるほどー、じゃあ頑張りますよぅ。
>> こっちも「すぐに使ってもらえないかもしれない機能」を
>> 実装するのはリスクがあって、すぐに確認・実践してもらえる
>> ことで、要件に合った仕様と品質を担保してから公開できるので。
>> (なので、大分安定を重視する時期に来たDBFluteでは要件のない
>> 機能はあえて実装せずに将来の機会を待つこともあります、
>> 今回のパターンはそのつもりでした...)
>> もちろん、実現コストに全て委ねられますが、あともうちょい頑張れば
>> できそうなので。(フィルタ処理はコールバックで遅延させます)
>>
>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>> fpです。
>>>
>>> 久保さん、ありがとうございます。
>>>
>>> 当方のプロジェクトでは、話に出た全パターン当てはまります。
>>>
>>> ただ、無理なようでしたら機能制限の範囲内で回避策を
>>> 考えますので、それほど緊急とはお考えにならないで下さい。
>>>
>>>
>>>
>>> すれちがってしまいましたね。>[seasar-dotnet:1861]
>>>
>>>
>>> (2010/10/11 18:26), kubo wrote:
>>>> 久保(jflute)です。
>>>>
>>>> ああ、なるほど、業務的one-to-oneのリレーションを
>>>> 通過した先の foreignTable のことですね。
>>>> しかも、今の仕様だと辿るリレーションの中で、
>>>> 業務的one-to-oneを含めることができないので、
>>>> 参照元テーブルから辿ることもできないですね。
>>>>
>>>> 業務的one-to-oneの参照先テーブルだけは特別に、
>>>> ポイントとして指定できる唯一の foreignTable、
>>>> もしくは、リレーションで特別に辿れる業務的one-to-one
>>>> というように扱えればってところですね。
>>>>
>>>> $$over(MEMBER_LOGIN.memberStatus)$$
>>>>
>>>> もしくは
>>>>
>>>> $$over(MEMBER.memberLoginAsValid.memberStatus)$$
>>>>
>>>> 該当の業務的one-to-oneが確定していない時点で、その奥の
>>>> リレーションを有効にしてエリアス名を取得できるかどうか、
>>>> その辺が実現の鍵になるので、ちょっと考えますね。
>>>> (場合に寄っては、置換処理をコールバックで遅延させて
>>>> 実行させるなどの工夫が必要かも...)
>>>>
>>>> ちなみに、fp さんの業務の中で、このパターンに
>>>> 当てはまるものがありますでしょうか？
>>>>
>>>> 2010/10/11 fp<[E-MAIL ADDRESS DELETED]>:
>>>>> fpです。
>>>>>
>>>>> 「OverRelation」を使わずに以下のようにできることは
>>>>> 認識しています。
>>>>>
>>>>> ; FK_MEMBER_MEMBER_LOGIN_AS_VALID = map:{
>>>>> ; localTableName = MEMBER ; foreignTableName = MEMBER_LOGIN
>>>>> ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
>>>>> ; fixedCondition =
>>>>> exists(select 'TRUE' from MEMBER_STATUS st
>>>>> where $$foreignAlias$$.LOGIN_MEMBER_STATUS_CODE =
>>>>> st.MEMBER_STATUS_CODE
>>>>> and st.DISPLAY_ORDER = 2)
>>>>> ; fixedSuffix = AsValid
>>>>> }
>>>>>
>>>>>
>>>>> (2010/10/11 16:44), fp wrote:
>>>>>> fpです。
>>>>>>
>>>>>> 久保さん、即座の御返事ありがとうございます。
>>>>>>
>>>>>> ん～、dbflute_exampledb にうまい例が見つからないのですが
>>>>>> 仮に、MEMBER -> MEMBER_LOGIN -> MEMBER_STATUS で
>>>>>> MEMBER_STATUS.DISPLAY_ORDER = 2 の条件で
>>>>>> MEMBER -> MEMBER_LOGIN に業務的one-to-oneなFKを設定できる
>>>>>> とした場合、
>>>>>>
>>>>>> ; FK_MEMBER_MEMBER_LOGIN_AS_VALID = map:{
>>>>>> ; localTableName = MEMBER ; foreignTableName = MEMBER_LOGIN
>>>>>> ; localColumnName = MEMBER_ID ; foreignColumnName = MEMBER_ID
>>>>>> ; fixedCondition =
>>>>>> $$over(MEMBER_LOGIN.memberStatus)$$.DISPLAY_ORDER = 2
>>>>>> ; fixedSuffix = AsValid
>>>>>> }
>>>>>> と書きたい、ということです。
>>>>>> 定義上明示されている MEMBER_LOGIN をポイントテーブルと
>>>>>> することに曖昧さがあるとは思わないのですが。
>>>>>>
>>>>>> いままさに定義しようとしているリレーションのための
>>>>>> 条件の指定に、以下は適用できませんし。
>>>>>>> MEMBER.memberStatusByFooCode というように、
>>>>>>> 明示的にリレーションを書いてもらう仕様にしています。
>>>>>>
>>>>>> foreignTable についての認識に齟齬があるのでしょうか？
>>>>>>
>>>>>>
>>>>>> (2010/10/11 15:56), kubo wrote:
>>>>>>> 久保(jflute)です。
>>>>>>>
>>>>>>>> とはいえ、foreignTable をポイントとすることはできないでしょうか？
>>>>>>>
>>>>>>> 例えば、会員に会員ステータスへのFKカラムが二つあった場合、
>>>>>>> ポイントを会員ステータスにするとになります。
>>>>>>> なので、foreignTableに関しては、
>>>>>>> MEMBER.memberStatusByFooCode というように、
>>>>>>> 明示的にリレーションを書いてもらう仕様にしています。
>>>>>>> 親の親の親の親の親のカラムとかになると、指定が長くて
>>>>>>> 大変ですが、曖昧さの可能性も増えるので、
>>>>>>> そこの優先度を練り直したって感じです。
>>>>>>>
>>>>>>>>> ポイントテーブルは ORDER_ITEM で、リレーションは order。
>>>>>>>>> -> $$over(ORDER_ITEM.order)$$
>>>>>>>>
>>>>>>>> これは実際の構成ではなく、あくまで例ってことで (^^;
>>>>>>>
>>>>>>> おっと、そうでしたかぁ、失敬w
>>>>> _______________________________________________
>>>>> seasar-dotnet mailing list
>>>>> [E-MAIL ADDRESS DELETED]
>>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>>>
>>>> _______________________________________________
>>>> seasar-dotnet mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>>> _______________________________________________
>>> seasar-dotnet mailing list
>>> [E-MAIL ADDRESS DELETED]
>>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>>>
>> _______________________________________________
>> seasar-dotnet mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>
> _______________________________________________
> seasar-dotnet mailing list
> [E-MAIL ADDRESS DELETED]
> https://ml.seasar.org/mailman/listinfo/seasar-dotnet
>
seasar-dotnet メーリングリストの案内