C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[8]: DBとその他言語間のI/Fについて

(過去ログ 138 を表示中)

[トピック内 11 記事 (1 - 11 表示)]　 << 0 >>

■80959 / inTopicNo.1)

　DBとその他言語間のI/Fについて

▼■

□投稿者/ ピロシキ (1回)-(2016/08/22(Mon) 18:25:01)

分類:[設計/仕様]　

一般的にどうなんだろう？
ということでご意見賜りたいです。
(個人的嗜好からのご意見でもかまいません。)

当方Oracle + JavaでWEBアプリを組むことが多いのですが、
画面単位に用意したDAOクラスにてゴリゴリと複雑なSQLを書いて、
結果を編集してUIに表示するプロジェクトしか経験しておりません。

で、これに最近違和感を感じ始めまして・・・。

DAOに書くSQLはJavaから見るとただの文字列ってのが気に入りません。
実行しないとSQL的に正しいか分からないですし。

かといって、画面ごとにプロシージャを用意してJavaからコールするのも、
JavaとDBのモジュールの結合が強すぎるような気がして
ベストな答えではないように思います。

ちなみに、O/Rマッパーは使用したことがありませんが、
複数テーブルを使用する複雑なSQLには向かない印象を持っています。
（いつかどこかで読んだ記事の印象です。）

皆様はどのような解をお持ちでしょうか？
（ぼんやりした質問で申し訳ありません。）

引用返信 編集キー/

■80980 / inTopicNo.2)

　Re[1]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ 作業着プログラマ (7回)-(2016/08/23(Tue) 08:23:23)

私なWindowsForm（C#)+SqlServerな組み合わせで仕事することが多いです。
その手の仕事を始めた当初はSQL文をコード上にゴリゴリ書いて、
運用が始まってから使用頻度の低いSQL分が間違ってたりして、
お客様にご迷惑をおかけしたことがしばしば・・・・
（テストをしっかりやれと言うのはおいといて・・・）

今はEntityFrameworkに切り替えたので、単純なSQL分間違いみたいな
トラブルはなく、コーディング時に指摘してもらえるので
私の中ではこれ以外の組み合わせの仕事がきたら、露骨に嫌な顔するほど楽ですね。
まぁ、パフォーマンスが出ない時にSQL直書きが完全になくなったわけではないですが。。。。

C#以外の仕事がたまたま無いのですが、JAVAもしくはそれ以外の環境でも
こういった技術が無いのか最近気になっています。

引用返信 編集キー/

■80982 / inTopicNo.3)

　Re[1]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ 真田昌幸 (44回)-(2016/08/23(Tue) 09:40:54)

■No80959 (ピロシキさん) に返信
> 当方Oracle + JavaでWEBアプリを組むことが多いのですが、
> 画面単位に用意したDAOクラスにてゴリゴリと複雑なSQLを書いて、
> 結果を編集してUIに表示するプロジェクトしか経験しておりません。
>
>で、これに最近違和感を感じ始めまして・・・。

なぜでしょう？
どのくらいの複雑なSQLかわかりませんが、
Java側で標準クラスが充実してない処理なら、
SQLで書くのが当然と思います。
DBに限らず帳票ツールなどの場合も同じです。

また、どこにもある機能(集計とか)は、
SQLでSumするより、Excelとか帳票ツールでSumしたほうが速いことが往々にしてあるので、
そうすることもあります。ただし、精度が問題になるなら、Excelでの集計はだめです。
内部処理が2進なので。
(表計算ソフトなのに、精度悪いってと思いますが。)

> かといって、画面ごとにプロシージャを用意してJavaからコールするのも、
> JavaとDBのモジュールの結合が強すぎるような気がして
> ベストな答えではないように思います。

C/Sが開発の中心の時代は、
DBサーバーのスペックがクライアントのPCより圧倒的にスペックが高いことが多かったので
サーバーサイドで処理する、ストアドプロシージャで処理するのが常識とされた時もあります。

しかし、今は、PCの性能も上がり、
負荷分散の考え方から、サーバーに処理を集中させることが非とされることもあるので、
ケースバイケースかと。

Webアプリの場合、アプリの処理もWebサーバーなので、
ストアドプロシージャで処理するメリットはWindowsアプリよりは無い気がします。

> ちなみに、O/Rマッパーは使用したことがありませんが、
> 複数テーブルを使用する複雑なSQLには向かない印象を持っています。
> （いつかどこかで読んだ記事の印象です。）

いや、書き方次第では？
むしろ、規約によって制約を受ける場合が多いと思います。
たとえば、ヒント句を使えば明らかにパフォーマンスが上がるケースでも、
ヒント句禁止の規約があって、SQL本体の修正を余儀なくされたり。

引用返信 編集キー/

■80983 / inTopicNo.4)

　Re[2]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ピロシキ (2回)-(2016/08/23(Tue) 10:06:33)

■No80980 (作業着プログラマさん) に返信
> 今はEntityFrameworkに切り替えたので、単純なSQL分間違いみたいな
> トラブルはなく、コーディング時に指摘してもらえるので
> 私の中ではこれ以外の組み合わせの仕事がきたら、露骨に嫌な顔するほど楽ですね。
> まぁ、パフォーマンスが出ない時にSQL直書きが完全になくなったわけではないですが。。。。

EntityFrameworkですか。
勉強不足で恥ずかしいですが、初めて聞きました。
ちょっと調べてみようかな。

O/Rマッパーにしてもそうなんですが、
触ってみてもないのにあーだこーだ言うなよ・・・と自分でも思います。
業務で色々な技術に触れる機会があればいいのですが、
そればっかりは自分でどうにかなりません。
かといって自前で環境作ってお勉強するほど
プライベートの時間に空きがない＆気力が起きないんですよね・・・。
（お目汚しすみません。愚痴＆言い訳です。）

引用返信 編集キー/

■80985 / inTopicNo.5)

　Re[2]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ピロシキ (3回)-(2016/08/23(Tue) 10:41:04)

■No80982 (真田昌幸さん) に返信
> ■No80959 (ピロシキさん) に返信
>>当方Oracle + JavaでWEBアプリを組むことが多いのですが、
>>画面単位に用意したDAOクラスにてゴリゴリと複雑なSQLを書いて、
>>結果を編集してUIに表示するプロジェクトしか経験しておりません。
> >
> >で、これに最近違和感を感じ始めまして・・・。
>
> なぜでしょう？
> どのくらいの複雑なSQLかわかりませんが、
> Java側で標準クラスが充実してない処理なら、
> SQLで書くのが当然と思います。
> DBに限らず帳票ツールなどの場合も同じです。
文章力がなくて、申し訳ないです。
SQLをゴリゴリ書くこと自体には違和感ないんです。
書く場所がJavaのクラス内、しかも文字列として・・・
ここに納得がいかないんです。

> Webアプリの場合、アプリの処理もWebサーバーなので、
> ストアドプロシージャで処理するメリットはWindowsアプリよりは無い気がします。
そうですね。
負荷の観点ではなく、DBのことはDBに任せたいといった
責任範囲(？)の観点でストアドプロシージャかな、と妄想してました。
JavaとDBの処理が分離できて、オブジェクト指向っぽいかなと。
ただ、SELECT処理だと返却する型をJava、DB双方意識するので
結合度が強いかな・・・と思った次第です。
（↑意味不明だったらご指摘ください。）

>>ちなみに、O/Rマッパーは使用したことがありませんが、
>>複数テーブルを使用する複雑なSQLには向かない印象を持っています。
>>（いつかどこかで読んだ記事の印象です。）
>
> いや、書き方次第では？
> むしろ、規約によって制約を受ける場合が多いと思います。
> たとえば、ヒント句を使えば明らかにパフォーマンスが上がるケースでも、
> ヒント句禁止の規約があって、SQL本体の修正を余儀なくされたり。
結局、色々な技術に触れてそれぞれのメリット・デメリットを勘案した上で
ケースバイケースでチョイスするべき・・・といった
当たり前の答えになるんでしょうね。
（こういった設計手法や、技術選択の課題に唯一無二の解がないのは重々承知しております。）

引用返信 編集キー/

■80999 / inTopicNo.6)

　Re[3]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ぶなっぷ (92回)-(2016/08/24(Wed) 10:45:23)

私の場合、SQLをゴリゴリ書きたくない場合は、Viewを作りますね。
で、コード側からは、直接Viewを開くだけ。
  Open("View名")
みたいな感じ。

少なくとも、これで、
「あれ、あのSQLどこだっけ？」
って、全コードgrepすることは無くなります。

引用返信 編集キー/

■81000 / inTopicNo.7)

　Re[4]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ 真田昌幸 (49回)-(2016/08/24(Wed) 11:35:37)

■No80999 (ぶなっぷさん) に返信
> 私の場合、SQLをゴリゴリ書きたくない場合は、Viewを作りますね。
> で、コード側からは、直接Viewを開くだけ。
> Open("View名")
> みたいな感じ。

アプリ側のソースの簡便化という意味では、
よく使われる手なので否定はしませんが、
多用しすぎはView定義書をきちっと残しておかないと、
元が何テーブルだっけ？ということになりがちです。

特にパフォーマンスが問題になってチューニングする必要がある場合は特に。
View同士を結合して、処理なんてことも往々にしてありがちなので。

引用返信 編集キー/

■81001 / inTopicNo.8)

　Re[5]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ピロシキ (4回)-(2016/08/24(Wed) 13:46:05)

■No80999 (ぶなっぷさん) に返信
> 私の場合、SQLをゴリゴリ書きたくない場合は、Viewを作りますね。
> で、コード側からは、直接Viewを開くだけ。
> Open("View名")
> みたいな感じ。

そうですね。
Viewも選択肢に入れるべきですね。

■No81000 (真田昌幸さん) に返信
> アプリ側のソースの簡便化という意味では、
> よく使われる手なので否定はしませんが、
> 多用しすぎはView定義書をきちっと残しておかないと、
> 元が何テーブルだっけ？ということになりがちです。

まあ、この辺はViewに限らず
ストアドプロシージャだろうがDAOゴリゴリだろうが
ドキュメントがいい加減だとどうにもならんですが。
Viewを選択する場合に、特に陥りやすい状況かもしれませんね。

> 特にパフォーマンスが問題になってチューニングする必要がある場合は特に。
> View同士を結合して、処理なんてことも往々にしてありがちなので。

確かに。
Viewをうっかりテーブル実体と同等に扱っちゃうことって
たまにあります・・・。(極たまにです。)

ただ、Viewを定義してなくても
DAOゴリゴリSQLの中にインラインビュー使い倒してたら
同じような問題が発生しえるわけで・・・。

結局どのような手法を選択するにしても、
お行儀が悪いSQLはお行儀が悪いなりにしか動かないですね。
なので、SQL周りの処理の専門家がいる前提で、
ゴリゴリSQLはJava開発者の生産物から除外したいです。
というのが、私の違和感の源かもしれません。

引用返信 編集キー/

■81003 / inTopicNo.9)

　Re[6]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ 真田昌幸 (50回)-(2016/08/24(Wed) 17:48:33)

.NetFrameworkの環境だと(VBでもC#でもやることはほぼ同じ)
ADO.netでDatatableにまず割り当てておいて、
GridViewのデータソースにDatatableを設定しておしまい。
てなことは当たり前のようにやりますね。
Windowsアプリの場合は特に。

Datatableもキーを設定しておけば、
世間で酷評されているほどパフォーマンスの問題は生じませんし、
アプリ側の開発工数削減としては有用かと。

ただし、あまり無理して、たくさんのデータを一時にもってくると、
SQLとかの問題でなくGridViewの描画とかGridViewのデータ反映時のイベントで
処理が重たくなるなんてことがあったりします。

便利だからと言ってやりすぎは何事もよくないわけで。

JAVA関連の技術でのDatatableに該当するオブジェクトは
どれくらい便利使えるのでしょうかね？

ちなみに、JSP等からのADO.netの利用は、理論的には可能なのかもしれませんが、
試している人が見当たりません。
旧ADOに接続したサンプルコードは逆に見つかりました。
JAVAでわざわざ親和性の高いJDBCを使わず、ADO.netを利用するメリットがあまりないので
使う人がいないのでしょう。

引用返信 編集キー/

■81046 / inTopicNo.10)

　Re[7]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ぶなっぷ (93回)-(2016/08/26(Fri) 09:25:11)

蛇足ですが。

SQLゴリゴリ と View には明らかな違いが１つあります。

SQLゴリゴリは、まずSQLの構文解析から始まり、構文解析結果に基づいて、
Join処理やフィルタ処理が行われ、結果表が返されます。

しかし、ViewだとSQLの構文解析処理がすっ飛ばされます。
なぜなら、Viewを作るということは、データベース側から見ると、SQL文を
保存しているのではなく、構文解析結果を保存しているからです。

結果表が１～数レコードにしかならないようなSQLを多数流すような場合、
構文解析処理の処理時間が馬鹿にできないので、明らかな性能差となって
現れます。

引用返信 編集キー/

■81087 / inTopicNo.11)

　Re[8]: DBとその他言語間のI/Fについて

▲▼■

□投稿者/ ピロシキ (5回)-(2016/08/29(Mon) 08:53:12)

ご意見いただいた皆様、ありがとうございました。

やはり「一般的にこうすべき・・・」といった
原則論のようなものはないのでしょうね。
今後も試行錯誤を重ねながら、
プロジェクトに最適なバランスを見つけるセンスを
磨いていかねば・・・と思った次第です。

ここら辺で「解決済み」とさせていただきます。

解決済み

引用返信 編集キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

- Child Tree -