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

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

掲示板トップ C# と VB.NET 入門 新規作成 利用方法 ツリー表示 トピック表示 ランキング 記事検索 過去ログ
ログ内検索
  • キーワードを複数指定する場合は 半角スペース で区切ってください。
  • 検索条件は、(AND)=[A かつ B] (OR)=[A または B] となっています。
  • [返信]をクリックすると返信ページへ移動します。
キーワード/ 検索条件 /
検索範囲/ 強調表示/ ON (自動リンクOFF)
結果表示件数/ 記事No検索/ ON
大文字と小文字を区別する

No.80959 の関連記事表示

<< 0 >>
■80959 　DBとその他言語間のI/Fについて
□投稿者/ ピロシキ -(2016/08/22(Mon) 18:25:01)

    分類:[設計/仕様]　

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

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

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

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

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

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

    皆様はどのような解をお持ちでしょうか？
    （ぼんやりした質問で申し訳ありません。）
親記事 /過去ログ138より / 関連記事表示
削除チェック/

■80980 　Re[1]: DBとその他言語間のI/Fについて
□投稿者/ 作業着プログラマ -(2016/08/23(Tue) 08:23:23)
    私なWindowsForm（C#)+SqlServerな組み合わせで仕事することが多いです。
    その手の仕事を始めた当初はSQL文をコード上にゴリゴリ書いて、
    運用が始まってから使用頻度の低いSQL分が間違ってたりして、
    お客様にご迷惑をおかけしたことがしばしば・・・・
    （テストをしっかりやれと言うのはおいといて・・・）

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

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

記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■80983 　Re[2]: DBとその他言語間のI/Fについて
□投稿者/ ピロシキ -(2016/08/23(Tue) 10:06:33)
    ■No80980 (作業着プログラマ さん) に返信
    > 今はEntityFrameworkに切り替えたので、単純なSQL分間違いみたいな
    > トラブルはなく、コーディング時に指摘してもらえるので
    > 私の中ではこれ以外の組み合わせの仕事がきたら、露骨に嫌な顔するほど楽ですね。
    > まぁ、パフォーマンスが出ない時にSQL直書きが完全になくなったわけではないですが。。。。

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

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

記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■80982 　Re[1]: DBとその他言語間のI/Fについて
□投稿者/ 真田昌幸 -(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本体の修正を余儀なくされたり。




記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■80985 　Re[2]: DBとその他言語間のI/Fについて
□投稿者/ ピロシキ -(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本体の修正を余儀なくされたり。
    結局、色々な技術に触れてそれぞれのメリット・デメリットを勘案した上で
    ケースバイケースでチョイスするべき・・・といった
    当たり前の答えになるんでしょうね。
    （こういった設計手法や、技術選択の課題に唯一無二の解がないのは重々承知しております。）

記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■80999 　Re[3]: DBとその他言語間のI/Fについて
□投稿者/ ぶなっぷ -(2016/08/24(Wed) 10:45:23) 
    私の場合、SQLをゴリゴリ書きたくない場合は、Viewを作りますね。
で、コード側からは、直接Viewを開くだけ。
  Open("View名")
みたいな感じ。

少なくとも、これで、
「あれ、あのSQLどこだっけ？」
って、全コードgrepすることは無くなります。
記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■81000 　Re[4]: DBとその他言語間のI/Fについて
□投稿者/ 真田昌幸 -(2016/08/24(Wed) 11:35:37)
    ■No80999 (ぶなっぷ さん) に返信
    > 私の場合、SQLをゴリゴリ書きたくない場合は、Viewを作りますね。
    > で、コード側からは、直接Viewを開くだけ。
    > Open("View名")
    > みたいな感じ。

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

    特にパフォーマンスが問題になってチューニングする必要がある場合は特に。
    View同士を結合して、処理なんてことも往々にしてありがちなので。
記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■81001 　Re[5]: DBとその他言語間のI/Fについて
□投稿者/ ピロシキ -(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開発者の生産物から除外したいです。
    というのが、私の違和感の源かもしれません。


記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■81003 　Re[6]: DBとその他言語間のI/Fについて
□投稿者/ 真田昌幸 -(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を利用するメリットがあまりないので
    使う人がいないのでしょう。
記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■81046 　Re[7]: DBとその他言語間のI/Fについて
□投稿者/ ぶなっぷ -(2016/08/26(Fri) 09:25:11) 
    蛇足ですが。

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

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

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

結果表が１〜数レコードにしかならないようなSQLを多数流すような場合、
構文解析処理の処理時間が馬鹿にできないので、明らかな性能差となって
現れます。
記事No.80959 のレス /過去ログ138より / 関連記事表示
削除チェック/

■81087 　Re[8]: DBとその他言語間のI/Fについて
□投稿者/ ピロシキ -(2016/08/29(Mon) 08:53:12)
    ご意見いただいた皆様、ありがとうございました。

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

    ここら辺で「解決済み」とさせていただきます。
記事No.80959 のレス / END /過去ログ138より / 関連記事表示
削除チェック/



<< 0 >>
パスワード/

- Child Tree -