【DBFlute.NET】外部結合データで想定されたデータが返却されてこない

[cuted...@gmail.com]

志水です。

こんばんは。

使用バージョン：dbflute-0.8.9.59

                            .NETFramework 4.5.2

外部結合した結果で想定されたデータが

返却されてこない事象が発生しています。

資料添付します。

additionalForeignKeyMapで定義した結合なのですが

ログから取得したSQLでの結果と相違した格納になっています。

添付資料のデータは本当はもっと沢山あるのですが

今回欲しいデータ（項目C3のUID0001042）を抜粋しています。

プログラム上での結果は

項目c85の7374のレコードが全て詰められて返却されてきています。

今までこんなことなかったのと思うんですが。。。

今までと違うのはfixedConditionを今回初めて使っています。

原因がわからないです。

ご教授お願い致します。

[kubo]

jfluteです

志水さん、こんにちは

SQLは合っているけど、Entityの検索結果がおかしいということですね。
ひとまず分析から。

「c85の7374のレコードが格納されて返却されてきています」
の部分のちょっとわからなかったのですが、
T_JINJI テーブルの値がT_KAMOKU テーブルの値に紛れてしまっている、
ってことでしょうか？
(具体的にどうおかしくなっているのかもう少し説明頂けると嬉しいです)

あと、SetupSelectを色々と外してみて、
現象が発生するケースとしないケースの境目を見つけて頂けないでしょうか？
(こういうときは現象が発生する最小のコードを見つけることが大切です)

[cuted...@gmail.com]

志水です。

こんばんは。

＞SetupSelectを色々と外してみて

試してみます。

すみません。説明不足でした。。

背景としては

T_SHOKU_SYU（職種テーブル）　⇒　職種の歴を管理しています。

T_JINJI（人事テーブル）　⇒人事異動の歴を管理しています。

T_KAMOKU（科目テーブル）⇒職種テーブルや人事テーブルの「SOK1000100100000000」の様な

コードを階層で管理し名称や集計コードなどを管理しています。

今回、以下のような所属分掌歴を作成するために、職種テーブルをもとに

職種の開始日の範囲にある人事テーブルを結合してその時に所属を取得し

科目テーブルは、職種テーブルと人事テーブルの職種名や所属先名を取得するために結合しています。

※各テーブルの各職員データ内で開始日付、終了日付が重複することは無いという想定です。

【所属分掌歴】

　　　　期間　　　　　　所属先　　　　職種

H10.04.01～H11.08.31 　▲▲▲支社　風紀指導職員

H11.09.01～H12.03.31 　▲▲▲支社　保健監視職員

H12.04.01～H15.03.31 　丸丸丸支社　茶道指導職員

H15.04.01～H19.09.30 　◇◇◇支社　剣術指導職員

H19.10.01～H99.12.31 　本　　　社　弓道指導職員

>「c85の7374のレコードが格納されて返却されてきています」 
>の部分のちょっとわからなかったのですが、 
>T_JINJI テーブルの値がT_KAMOKU テーブルの値に紛れてしまっている、 
>ってことでしょうか？ 
>(具体的にどうおかしくなっているのかもう少し説明頂けると嬉しいです) 

C0～C20が職種テーブルで

c85（機械番号）以降は人事テーブルのデータなのですが

c85（機械番号）のキーだけを抜粋して説明すると

本来はEXCELに張り付けたデータのように

結合されるデータは、c85（機械番号キー）でいうと下記の【本来】の

それぞれの条件にあった人事データが取得されなければならないのに

プログラム実行した場合は【ＰＧ】のように

全て同じ人事データが格納（取得）されています。

【本来】　　　　【ＰＧ】

7374　　　　⇒　　7374　

7374　　　　⇒　　7374　

7374　　　　⇒　　7374　

7374　　　　⇒　　7374　

7375　　　　⇒　　7374　

7376　　　　⇒　　7374　

7377　　　　⇒　　7374　

出力例でいうと

【本来】はこう出力されるはずなのですが

【所属分掌歴】

　　　　期間　　　　　　所属先　　　　職種

H10.04.01～H11.08.31 　▲▲▲支社　風紀指導職員

H11.09.01～H12.03.31 　▲▲▲支社　保健監視職員

H12.04.01～H15.03.31 　丸丸丸支社　茶道指導職員

H15.04.01～H19.09.30 　◇◇◇支社　剣術指導職員

H19.10.01～H99.12.31 　本　　　社　弓道指導職員

【ＰＧ】では以下のように全て同じ所属で出力されてしまいます。

【所属分掌歴】

　　　　期間　　　　　　所属先　　　　職種

H10.04.01～H11.08.31 　▲▲▲支社　風紀指導職員

H11.09.01～H12.03.31 　▲▲▲支社　保健監視職員

H12.04.01～H15.03.31 　▲▲▲支社　茶道指導職員

H15.04.01～H19.09.30 　▲▲▲支社　剣術指導職員

H19.10.01～H99.12.31 　▲▲▲支社　弓道指導職員

2019年3月6日水曜日 16時19分01秒 UTC+9 jflute:

[kubo]

jfluteです

詳しく説明ありがとうございます。

SetupSelectした人事テーブルのデータが、
すべて最初のレコードになってしまっているというところですね。
(途中から違うレコードが関連付かないといけないはずなのに)

ふむぅ...

職種テーブルの uniqId は、PKでしょうか？

職種テーブルの uniqId と人事テーブルの uniqId で、
FKの関係性になっているのでしょうか？
(人事テーブルが職種テーブルをFK制約で参照しているとか)


> ＞SetupSelectを色々と外してみて
> 試してみます。

ひとまずこちらお願いします。

SetupSelect_TJinji() のみにしたらどうなるか？
(職種のSetupSelectが絡んでないかの切り分け)
など。


もう一つ、人事テーブルに関する業務的one-to-oneも、
fixedSuffixを付けてみて頂けないでしょうか？
(一つだけでも業務的な意味合いを付けるためにfixedSuffixはよく付けています)
(科目テーブルの一個目の業務的one-to-oneも同じではあります)

[cuted...@gmail.com]

こんばんは。

志水です。

すいません返信遅くなりました。

この問題が出ている案件の納期だったので調査に着手することができませんでした。

非同期の台帳出力なので多少の時間がかかっても良いと判断して

とりあえず別途人事データを取得するようにして回避しました。

職種テーブルの uniqId は、PKでしょうか？

テーブル定義抜粋しました。

職種テーブルの uniqId と人事テーブルの uniqId で、
FKの関係性になっているのでしょうか？
(人事テーブルが職種テーブルをFK制約で参照しているとか)

テーブル定義抜粋しました。

 

> ＞SetupSelectを色々と外してみて
> 試してみます。

ひとまずこちらお願いします。

SetupSelect_TJinji() のみにしたらどうなるか？
(職種のSetupSelectが絡んでないかの切り分け)
など。

 

事象はかわりませんでした。

 

もう一つ、人事テーブルに関する業務的one-to-oneも、
fixedSuffixを付けてみて頂けないでしょうか？
(一つだけでも業務的な意味合いを付けるためにfixedSuffixはよく付けています)
(科目テーブルの一個目の業務的one-to-oneも同じではあります)

 

やってみましたが事象はかわりませんでした。

    ; FK_T_SHOKU_SYU_T_JINJI = map:{

        ; localTableName  = T_SHOKU_SYU

        ; localColumnName = uniqId

        ; foreignTableName  = T_JINJI

        ; foreignColumnName = uniqId

        ; fixedCondition = 

          $$foreignAlias$$.START_YMD <= $$localAlias$$.START_YMD

      and $$foreignAlias$$.END_YMD >=  $$localAlias$$.START_YMD

        ;fixedSuffix = Soshiki

 以上、宜しくお願い致します。

[kubo]

jfluteです

志水さん、とりあえず回避されたということでりょうかいです。
確認もありがとうございます。


こちらでも似たようなスキーマを作って確認してみました。
(.NET版の動作確認環境を持っていないのでJava版になりますが)

// WxBizManyToOneNonUniqueTest.java | dbflute-test-dbms-mysql
https://github.com/dbflute-test/dbflute-test-dbms-mysql/blob/master/src/test/java/org/docksidestage/mysql/dbflute/whitebox/dfprop/addifk/WxBizManyToOneNonUniqueTest.java

正常にマッピングされ、再現しませんでした。


このケースは業務的one-to-oneではなく業務的many-to-oneという特殊なものですが、
もしかしたら、これは仮説ですが...
「.NET版の業務的many-to-one」が対応されていないのかもしれません。
(他のケースの業務的many-to-oneを試してみないとなんともですが...)

とりあえず回避されたおいうことなので、
もし、また似たようなケースがありましたらご連絡ください。


一方で、お約束ですが、どのみち本来は、
SHUKUSYU から JINJI への物理FKカラムがあったほうが良いのではないかとは思います。
そもそも業務的many-to-oneが必要にならないように正規化を意識していくほうが良いです。


# ちなみに、テキストファイルや画像ファイルなどはメールに直接添付しても構いません。
# 逆にエクセル(Excel)ファイルを開けない人がいると思いますので。
# (自分もたまたま開けたので閲覧はできましたが、そのうち環境変わると開けなくなるかも...)

[cuted...@gmail.com]

志水です。

お試し頂いてありがとうございます。

条件によるのかもしれませんが基本的に

「.NET版の業務的many-to-one」は避けたほうがいいみたいですね。

＞SHUKUSYU から JINJI への物理FKカラムがあったほうが良いのではないかとは思います。

＞そもそも業務的many-to-oneが必要にならないように正規化を意識していくほうが良いです。

そうなんですよねー。

本来なら人事（所属）に対して職種（に人事キーとか）をつけていけばよかったのかもですが。。

移行元アプリのデータがかなりいい加減でかなりデータを整理したのですが

それでもデータ移行後の人事の付け直しの件数は多くて、人事の付け直しをすると

職種も付け直しになってしまうので（絶対、クレーム対象になりそうな・・）

なるべく操作手順の複雑化や入力しなおしを避けたいのと

歴同士のデータ依存をあまり強めたくなかったことからこういう

設計になってしまってますね。

もっと熟慮すれば回避できたかもしれない設計ですが

なにぶん入札案件の安価で時間も人もいない設計＝製造スタイルなので（笑）

＞# ちなみに、テキストファイルや画像ファイルなどはメールに直接添付しても構いません。
＞# 逆にエクセル(Excel)ファイルを開けない人がいると思いますので。
＞# (自分もたまたま開けたので閲覧はできましたが、そのうち環境変わると開けなくなるかも...)

そうか、意識してなかったです。

了解です。。

以上、ありがとうございました。

2019年3月31日日曜日 15時50分41秒 UTC+9 jflute: