SQLServerのシノニムについて

[志水正幸]

志水です。

お世話になっております。

「[dbflute users 2472] SQLServerのManualPagingについて」と

同じ案件の中で、シノニムを作成しているのですが

シノニムを認識できていないようです。

これもORACLEときは問題なくできていたのですが

下記の設定はORACLE接続時の設定より引き継いでいます。

1. databaseInfoMapのvariousMapのobjectTypeTargetListにSYNONYM

2. databaseInfoMapのpropertiesMapにincludeSynonyms

もしかしてSQLServerのシノニムは未対応ですか？

以上、よろしくお願いいたします。

[kubo]

jfluteです

おおぉ、そもそもSQLServerにSynonymがあることを知りませんでした。
(昔からあったかなぁ...)

いま、テストしているのはOracleのみです。
DBFluteのSQLServerのドキュメントにもSynonymの記述はありません。
http://dbflute.seasar.org/ja/manual/reference/dbway/sqlserver/index.html

ただ、SQLServerのJDBCドライバーが、SQLServerのSynonymをどう扱いか？
っていうところ次第ですね。その辺の情報ってあります？

[志水正幸]

志水です。

＞ただ、SQLServerのJDBCドライバーが、SQLServerのSynonymをどう扱いか？ 
＞っていうところ次第ですね。その辺の情報ってあります？ 

JDBCでSynonymの一覧取得している人がいたので

扱うことはできると思います。

http://groovyarekore.blogspot.com/2009/10/groovysql-server_07.html

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

2019年10月25日金曜日 15時13分23秒 UTC+9 jflute:

[kubo]

jfluteです

> JDBCでSynonymの一覧取得している人がいたので
> 扱うことはできると思います。

ありがとうございますー。ただ、sys.synonyms を直接selectしてますね。
JDBCのメタデータとして取得できるか検証が必要ですね。

案件的に、Synonym経由でのアクセスは必須なのでしょうか？
上記のJDBC周りの調整するのは難易度高いと思うので、
参照元のテーブルを使えるならその方が早いと思います。

[志水正幸]

志水です。

ありがとうございます。

ORACLEはあったけど

SQLServerでのメタデータ取得しているような記事は見当たらないですね。。

無理なのかなぁ・・

SQLServerは2005あたりからシノニムできるようになったみたいですね。。

＞JDBCのメタデータとして取得できるか検証が必要ですね。

この辺ほぼ知識ないので何言ってんだ？と思うかもですが

メタデータを取得できないと

SELECT などでシノニムのデータにもアクセスできないということでしょうか？

それとも、エンティティなどの定義回りを生成できないということでしょうか？

シノニム定義元のシステムのエンティティクラスとかから

シノニム側のシステムの定義回りを生成とかできないですかね？？

＞案件的に、Synonym経由でのアクセスは必須なのでしょうか？ 

現状は「できれば」というところです。

今回の案件でいえば

シノニム定義元のシステムもウチのシステムなので

最悪、２システムのテーブルを一つのＤＢにまとめてしまえばと

考えています。ただテーブル名に同じ名前が存在するので

この辺の名前変更が必要ですが、こちらの難易度は力技なので私向きです（笑）

しかし将来的には欲しい機能ではありますね。。。

[kubo]

jfluteです

とりあえず、OracleのSynonymのときにあったことを書いておきますね。

1. まず、dfpropに二つの設定を入れないとSynonym自体がメタデータ取得できない
　=> http://dbflute.seasar.org/ja/manual/reference/dbway/oracle/index.html#synonym

2. でも、PK, FKのメタデータが取得できないのでデータディクショナリ直接参照
　=> https://jflute.hatenadiary.jp/entry/20090226/1235632161

さらにOracleの場合、DBリンクのSynonym, プロシージャのSynonymの処理がありました。
そして、JDBCのメタデータで足りない情報は、データディクショナリを直接selectして、
補完するようにしました。

なので、SQLServerでも同じことをするためには、
SQLServerのデータディクショナリを参照する特別な処理を入れる必要があるでしょう。
DfSynonymExtractorOracle.java の SQLServer 対応クラスを作りイメージです。

// DfSynonymExtractorOracle.java (OracleのSynonym取得の実装クラス)
https://github.com/dbflute/dbflute-core/blob/3508b660035f50f6ab0b38e6cdcf982b69dd2285/dbflute-engine/src/main/java/org/dbflute/logic/jdbc/metadata/synonym/DfSynonymExtractorOracle.java

OracleはまだSynonym自体の存在はJDBCのメタデータで認識できていますが、
SQLServerだとそれすらできないかもしれないので、
その時点からデータディクショナリが必要になるかもしれません。
(プルリクはいつでもWelcomeです)

...

そして、一つ思いついた回避策として思い付いたのはadditionalTableMap.dfprop です。

OracleのDBリンクSynonymだと、Synonymの存在自体は認識しても、
カラム情報すら取得できないということがありました。
その回避策として additionalTableMap.dfprop を話題になったことがあります。
(その後、DBリンクSynonymも頑張ってメタデータ補完したので要らなくなりましたが)

// additionalTableMap.dfprop のドキュメント
http://dbflute.seasar.org/ja/manual/reference/dfprop/additionaltable/index.html

// additionalTableMap.dfprop の Example
https://github.com/dbflute-test/dbflute-test-dbms-derby/blob/master/dbflute_maihamadb/dfprop/additionalTableMap.dfprop

// additionalTableMap.dfprop の実装クラス
https://github.com/dbflute/dbflute-core/blob/master/dbflute-engine/src/main/java/org/dbflute/properties/DfAdditionalTableProperties.java#L41

要は、テーブルのメタデータを人間がdfprop経由でDBFluteに直接教えてあげるってことです。
DB変更時の追従が無くなってしまいますが、全く何もできないよりはマシということで。
(なので参照テーブルと構造が同じことをチェックする自動テストを書くと良いでしょう)

...

> シノニム定義元のシステムもウチのシステムなので
> 最悪、２システムのテーブルを一つのＤＢにまとめてしまえばと
> 考えています。ただテーブル名に同じ名前が存在するので

細かい構成がわかりませんが、DBは分かれたままで、
シノニム定義元のシステムのデータベース (or スキーマ) のテーブルを、
直接selectさせてもらうってことはできないのかな？と思いました。
要は単純なDBFluteクライアント二つにする複数DBで互いに自動生成して、
Synonym経由ではなく互いのテーブルをそれぞれ直接selectするようなイメージです。
(まあ、権限的に無理とか、隠蔽したいものがどうしてもあるというのかもしれませんが)

一方で、最近だとこういうパターンは、
別システムのJSON API経由でデータを参照する方が多いです。
そもそも別のシステムのテーブルを直接selectしないほうが、
DBスキーマの依存が限定的になるので良いということで。
(一つのDBを複数のシステムで参照するような構成はもうあまり見かけないですね)

[志水正幸]

志水です。

色々書いていただきましたが、前半部分は

私には敷居が高すぎることがわかりました。

難しすぎる・・・

後述の複数DBも考えましたが

そのあとの、Json APIとかを使った方法ですが

これって外部からの接続口を設けるってことですよね？

シノニム定義元のシステムは職員の管理システムなので

こういうやり方の方が、他システムとの接続が楽になりそうですね。

良いアイデアを頂きました。

この案で検討してみたいと思います。

私にはちょっと難しそうですが、やり方の記事を探してみます。

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

[kubo]

jfluteです

> そのあとの、Json APIとかを使った方法ですが
> これって外部からの接続口を設けるってことですよね？

そうです。

例えば、志水さんのシステムを「seaシステム」と呼んで、
別の職員の方のシステムを「landシステム」と呼ぶとします。

「seaシステム」は「sea DB」を管理していて、
「landシステム」は「land DB」を管理しているとします。

そして「seaシステム」から「land DB」のデータも参照するとなった場合...

同じDBインスタンスであれば確かにSQLで直接参照することはできます。
(シノニム経由か直接テーブルかは別として)

この場合、joinもできるので、密に連携しやすいのがメリットです。
一方で、「landシステム」の都合で「land DB」に何か変更があった場合、
「seaシステム」の「land DB」に対するSQLにも気を使わないと、
変更ができなくなるのがデメリットです。
(気付いたら「seaシステム」のSQLが落ちてるとかの可能性も)

ゆえに、
「seaシステム」は「sea DB」しか参照しない、
「landシステム」は「land DB」しか参照しない、
というのをベースにして...

もし「seaシステム」で「land DB」見たくなったら、
「landシステム」からWebリクエスト経由(JSON形式など)でデータをもらう、
というのがよくある構成です。
(身の回りでは、ほぼほぼそうやっています)

「seaシステム」→「landシステム」→「land DB」

SQLで別DB間のjoinができなくなりますが、ある程度は割り切りというのと、
そもそも頻繁にjoinをしたくなるような依存度であれば、
システムも無理に分けないほうがいいのかなぁとかも。

一方で、「landシステム」に「seaシステム」から叩かれる用のAPIを作るわけですが、
(まあ「seaシステム」専用というよりも、できるだけ汎用的に作りたいですが...)
誰が作る？ってのが場合によっては決めづらいこともあるかもですね。
縦割りが激しい現場だと、その辺が揉めがちです笑。(仲が良いのが一番^^)

[志水正幸]

志水です。

＞SQLで別DB間のjoinができなくなりますが、ある程度は割り切りというのと、
＞そもそも頻繁にjoinをしたくなるような依存度であれば、
＞システムも無理に分けないほうがいいのかなぁとかも。

確かに、今回は経理システムから職員管理システムにアクセスして

所属とユーザ情報の認証と認証した職員名等を取得したいだけだし

それ以上のことはそうそう必要ないことですね。

＞一方で、「landシステム」に「seaシステム」から叩かれる用のAPIを作るわけですが、

＞(まあ「seaシステム」専用というよりも、できるだけ汎用的に作りたいですが...)
＞誰が作る？ってのが場合によっては決めづらいこともあるかもですね。
＞縦割りが激しい現場だと、その辺が揉めがちです笑。(仲が良いのが一番^^)

そういう現場だと、仕事増やしたくないからたらい回しになりそうですね（笑）

その点、ウチは自分１人で開発しているので揉める心配はないです（笑）

けど、逆に大きい現場のように知識を増やしたり疑問を聴ける機会や

忙殺されて勉強する機会がほぼ無いので、今回のようにJson APIのことなど

最近の事情や技術手法を知れてうれしいですね。

また、いろんなこと教えてください。

[kubo]

jfluteです

> けど、逆に大きい現場のように知識を増やしたり疑問を聴ける機会や
> 忙殺されて勉強する機会がほぼ無いので、今回のようにJson APIのことなど
> 最近の事情や技術手法を知れてうれしいですね。
> また、いろんなこと教えてください。

はい。ぜひ、こういうコミュニティをご利用くださいませ（＾＾。
オープンに相談して頂けることで、他の人も参考になりますから。


※自分も、SQLServerのシノニムを初めて知って勉強になりました。