Q&A
ご自身の裁量ではどこまで決められるのでしょうか。
リファクタリングを任されたということですか？
お世話になります。
調べてみたのですがどうしても分からなく質問させてください。
初めての投稿です。何か不手際等ありましたら、ぜひ容赦なくご指摘下さい。
#実現したいこと
ソースコード上でのクエリ管理（クエリのベタ打ち）をやめる
#####※ソースコード上でのSQL管理の例
Dim IsQuery as String = ""
IsQuery &= "SELECT AAA, "
IsQuery &= " BBB, "
#実現したい理由
・クエリの修正（保守性？）が面倒
・プログラム内の変数や定数をクエリに織り交ぜる作業が面倒
#####「クエリに織り交ぜる」の例
Const AAA as string = "aaa"
Dim ItemName as string
～～～～～
IsQuery = &= "CASE " & ItemName & "='" & AAA & "' "
IsQuery = &= ～～～～
#調べてみた限りの打ち手の候補
- テキストファイルに外出しする
どのようにパラメータを突っ込むのかがイマイチわからない。
- ストアドプロシージャを使う
管理が大変ではないか？という懸念があります。
大量にストアドがあった場合、何をどのプログラムで使うのかが物凄く分かりにくい気がします。
- LINQを使う
調べた限り、LINQを使用すれば、ベタ打ちは無くなると思いました。
自社ではLINQは一切使っておらず、私も殆ど書けませんので勉強は必要になりますが、
上記2つよりも有力であれば、率先して身につけて行きたいと考えています。
#その他お伝えしたい事
当方新米プログラマなのですが、自社のプログラムでは、全てのクエリでコード上のベタ打ちを行っており、（技術的に15年前くらいから時が止まっています）これをもう少しスマートに管理出来ないのか？というのを調べています。
色々と方法はあるようですが実際にどれが良いのか分かりかねた為、質問させていただいた次第です。
お知恵をお貸し下さい。
どうぞ宜しくお願い致します。
#追記1（私の社内での立場、裁量権の有無）
私は古いコードを刷新するためのPJメンバーとして活動予定です。
合理的なリファクタであることが説明できれば、最大限の変更が認められます。
#追記2（社内の開発レベル）
付け加えておきますと、はっきり言って、技術レベルの低い人が多く、あまりレベルの高い技術になるとついてこれない人間が多くなる事が想定されます。
#ベストアンサーについて
どなたからも大変有益な情報を頂き、大変迷ったのですが、他の方が当質問を見た際に、一番直接的な答えになってそうに思えたため、gentaroさんのアンサーをベストアンサーとさせて頂きました。
皆様、大変ありがとうございました。重ねて御礼申し上げます。
ご返信ありがとうございます。
情報不足で申し訳ありません。
私は古いコードを刷新するためのPJメンバーとして活動予定です。
合理的なリファクタであることが説明できれば、最大限の変更が認められます。
付け加えておきますと、はっきり言って、技術レベルの低い人が多く、あまりレベルの高い技術になるとついてこれない人間が多くなる事が想定されます。
「一般的な考え方」程度になります。
あくまで赤の他人なので。
>技術レベルの低い人が多く、あまりレベルの高い技術になるとついてこれない人間が多くなる事
底上げするしかないですよ。
でないと、自社の未来はないです。
多くを外注するなら別にそれでもいいでしょうけど。
>底上げするしかないですよ。
>でないと、自社の未来はないです。
やはりそうですよね。
大変厳しい状況ですが、先陣を切ってやっていきたいと思います。
率直なご意見、大変ありがたいです。
LINQ はデータベースのすべての機能が使えるわけではありません。今まで SQL で行っているなら無理に変換することでバグが入る可能性もあります。パラメータの入れ方はデータベースによって多少違いますが、特に難しくないので、それを使うのが良いと思います。
Zuishin様
コメントありがとうございます。
おっしゃる点、気になっていました…。
複雑なクエリをどうやってLINQで表現するのであろう？と。
比較的単純なクエリであればLINQで代用していく、といった形が良いのでしょうか。
>パラメータの入れ方はデータベースによって多少違いますが、特に難しくないので、それを使うのが良いと思います。
→大変申し訳ありませんが、もし差し支えなければ、パラメータの入れ方を参考URL等でご教示いただけませんでしょうか。探してみたのですがどうしても見当たらず…。
当方SQLServerを使っています。
ここにサンプルがあります。
https://docs.microsoft.com/ja-jp/dotnet/framework/data/adonet/configuring-parameters-and-parameter-data-types
まず SQL の動的な部分を @(パラメータ名) に置き換えます。たとえば以下の SQL の場合
"select * from " + tableName + " where id = " + id
次のように置き換えらえます。
"select * from @TableName where id = @Id"
次に SqlParameter を作成し、パラメータ名と値を関連付けます。
そして SqlCommand に Parameters.Add で作成したパラメータを関連付けます。
これは上記リンクを参考にしてください。
後は今まで通りです。
いちいち SqlParameter を作って Add するのは面倒なので、それを補助する関数を作るのが良いと思います。
Zuishin様
ご回答ありがとうございます。
すごく分かりやすくご説明頂き、ありがとうございます。
パラメータを使うだけでも、だいぶと改善すると感じました。
ありがとうございますm(_ _)m
回答4件
0
新人プログラマということで大変かと思いますが、質問の内容を見る限り
自分たちだけでやるのは厳しいように見受けました。
自分たちである程度出来るスキルが無いのであれば、外部のIT技術者派遣サービスの
利用を検討するか、経験者を中途採用するかを検討してみてはいかがでしょうか？
私自身は利用したことはありませんが、世の中にはそういったことを専門に
している会社も存在します。
一つの案として上程してはどうでしょう。
投稿2021/01/20 07:35
総合スコア418
>経験者を中途採用するかを検討
ここに大きく同意しました＋１
ご回答ありがとうございます。
全くもって仰るとおりで、おそらくは自分たちだけでやるのは厳しいと感じています。
（そう思いつつも、一歩ずつ進むしかないだろう、というような心境です。）
経験者の採用に関しては、特定されてしまう恐れがあるので詳細は述べられませんが、
相当厳しいと判断しています。
頭に全くありませんでしたが、外部のIT技術者派遣サービスの利用を検討するという手段は
魅力的に思いました。調べた上で上程してみます。
大変貴重な観点を教えて頂き、ありがとうございました。
まあ、VB.netの経験者の中途市場自体が小さいので、採用を本気で考えても
中々ハードルは高いんですよね。。。
そういうこともあり、外部のIT技術者派遣サービスもお勧めしてみました。
いずれにしても、自分達のスキルアップも図る必要はあるかと思いますので
頑張って下さい。
折角なので、スキルアップを図る案も一つ提案してみます。
こちらもお金は掛かりますが、社員何名まで月額幾らでIT系（プログラム、DB、ネットワーク等）や
社会人マナー等様々な内容の講義や過去の講義の動画を受けることが出来るサービスがあります。
自分たちで1から学習しようとしても取っ掛かりが掴めない場合はこのようなサービスを
取っ掛かりにするのも一つの手かと思います。
案が通ったら儲けくらいの気持ちで上程してみてはいかがでしょうか。
ご返信ありがとうございます。大変助かります。
はい。他にも超えるべきハードルがいくつもあるような状態でして…（笑）
スキルアップを図る案のご提示、ありがとうございます。
大変興味深いです。懐の許す範囲で個人的に受けてみたいぐらいの気持ちです。
もし差し支えなければ、サイト名を教えて頂くことなどはできますでしょうか？
どうぞ宜しくお願い致します。
IT企業研修辺りのキーワードで検索すると色々出てきます。
社員の研修は助成金制度が活用できますので併せて提案すると良いかと思います。
どこがお勧めかは会社の規模等にもよるかと思いますので、比較サイト等を参考にしてみて下さい。
返信が滞ってしまい、大変申し訳ありません。
助成金制度が活用できるというのは社内へ提案するにあたって大きな追い風です！
重要な観点をご提示して頂き、本当にありがたかったです。
ありがとうございましたm(_ _)m
0
相当量のコードもありそうですし、検証の期間も必要でしょうね。
LINQという候補があるのでしたら、まずはそこを試してみるところからでしょうね。
「今のやり方を踏襲した最小限のコード」を作ったうえで、移行の手順を確立する。
「何が適切か」というのは他人には判断できませんし、今までやってないことをやるのでしたら
結局検証コストも学習コストも相応以上にかかります。
「良さそうなもの」を片っ端から試していって合いそうなものを見つけるしかないと思います。
私の昔の話ですが、
「あるまとまった機能を実装するためにライブラリやフレームワークを幾つか検証した結果、汎用性の高さを重視すべく自作することになった」ということも結構あります。
投稿2021/01/20 07:21
総合スコア80875
ご回答ありがとうございます。
「何が適切か」について、ある程度明確な答えがあるのだろうと踏んでいましたが、そうではないのですね。
おそらくは私の頭にない観点が隠れているのだと思いました。（ある側面で見ればこれが良いが、この側面で見ると悪い、等）
入社後日を追うごとに、自社の技術レベルの圧倒的低さを痛感しており、新しい技術を身に着けていく事の必要性を強く感じております。
（ちなみにですが、ライブラリやフレームワークも全くと言って良いくらい使っていません…そもそも「ライブラリ」や「フレームワーク」といった言葉について、私を含む開発メンバー全員が、何となくしか理解できてないレベルです。）
少し脱線してしまいますが、上記の観点から言えば、「LINQを使用する」方向で進めた方が良いのだろうと思いました。「新しい技術を使う」という意味において。
有益なご回答、ありがとうございました。
>ライブラリやフレームワークも全くと言って良いくらい使っていません
「そういう方針」でやってるところは少なからずありますよ。大手でもね。
顧客にとっては何で作ってあろうと関係なく、要件を満たされて不具合なく使えてサポートがなされていればそれでいいわけですしね。
フレームワークなどはアップデートによってコアソースが容赦なくかきかわったりするので
それに対応していくのも結構大変です。使わない機能も含まれていたりするので、相対的にプログラムの容量や動作は遅くなりがちです。
その点、一通り自社で構築した仕組みなら勝手知ったるということで、汎用性も高く、それなりの保守のしやすさもあるでしょう。（設計書残ってればいいですけど）
中には言語基礎をやったら次は自社構築の開発標準を学ばせるところもあるようです。
それなりに年数や案件をこなしてきているのでしたら、一概に「技術が低い」とは言えないのではと思います。
まあいずれにしても、１個に絞らず、複数候補を出して十二分に検証していくことでしょうね。
ご返信ありがとうございます。
このような会話自体、自社では生まれてこないので、誇張なしに物凄くありがたいです。
>フレームワークなどはアップデートによってコアソースが容赦なくかきかわったりするので
それに対応していくのも結構大変です。使わない機能も含まれていたりするので、相対的にプログラムの容量や動作は遅くなりがちです。
→便利な側面だけ見えていましたが、そういった側面もあるのですね。
勉強になりました。
>自社で構築した仕組みなら勝手知ったるということで、汎用性も高く、それなりの保守のしやすさもあるでしょう。（設計書残ってればいいですけど）
自社で構築した仕組みではあるのですが、設計書もなければ、バグも頻発しているような代物でして…（お恥ずかしい限りですが…）
きちんとしたクオリティのプログラムを作成したい気持ちが強いです。
>それなりに年数や案件をこなしてきているのでしたら、一概に「技術が低い」とは言えないのではと思います。
→年数も案件もこなしているのですが、何もかもが自社で完結している（詳しくは申し上げられませんが、「特定の範囲の企業様に毎回同じようなプログラムを作成している」会社と考えていただければわかりやすいと思います）ため、古いままでも今まではあまり困らなかったという経緯があります。
が、しかし、案件をよそから貰って来て開発するとなった場合、おそらくレベルが低すぎて使い物にならない人材が多数、といった事態になりそうです。
>まあいずれにしても、１個に絞らず、複数候補を出して十二分に検証していくことでしょうね。
→技術の幅を拡げるという意味でも、必要な取り組みに感じました。
実践させて頂きます。ありがとうございます。
0
ベストアンサー
生のSQLを使う方針を維持するのであれば、結局の所「管理が大変」から逃れるのは難しいんじゃないでしょうか。
「管理」という言葉の指す内容にもよりますが。
基本的にはIDEによる支援が受けにくいプレーンテキストになってしまうんで、質問文の候補に出ているどの方法をとっても修正する際の手間は大して変わらないような気がします。
どの程度複雑なクエリを使っているのかわかんないけど、単純なものが多いのであればEntity Frameworkを使うなど、自前で書くクエリを減らす方向にすれば「SQLの管理」からはある程度開放されるでしょう。既存クエリの内容によっては難しい可能性もあるので、場合によってはストアドプロシージャを組み合わせたりする事も考える必要はあるとは思います。その数が多いとどうしようもないけど。
規模感も内容もわかんないんで何とも言えないけど、そもそもクエリでやろうとしている事が正しいのか（必要以上にSQLに頼りすぎてないか）とか、そういう観点からも見直した方が良いと思いますがね。
SQLで複雑なデータ加工をするぐらいなら、必要最低限のデータをSELECTしてアプリ側で加工した方がシンプルになる場合も往々にしてあるので。
投稿2021/01/20 12:02
総合スコア8947
ご回答ありがとうございます。
>生のSQLを使う方針を維持するのであれば、結局の所「管理が大変」から逃れるのは難しいんじゃないでしょうか。「管理」という言葉の指す内容にもよりますが。
→「管理」という言葉を使いましたが、率直に言うと、フォームのソースにクエリをベタ打ちする事が明らかに「古い」と認識しており、それをよりモダンに運用していきたい、という気持ちが強いです。
モダンに運用することで、管理面でも今よりは楽になるであろう、という意味合いでした。
しかし、大体どの方法を使っても、手間はあまり変わらないのですね。
自社の現状では、RDBにアクセスする際は必ずSQLを使っています。
存じ上げませんでしたが、SQLを使わないという選択肢もあるのですね。
少し調べてみたいと思います。有益な情報ありがとうございます。
>SQLで複雑なデータ加工をするぐらいなら、必要最低限のデータをSELECTしてアプリ側で加工した方がシンプルになる場合も往々にしてあるので。
→一応、これを考えたことはあるのですが、処理速度が落ちてしまうのが気になり…自社のスタンダードは「クエリ一発で（加工も含めて）1度に取ってこれるなら、それが一番早くて良い」というものになっています。
SQLにこだわりがあるんなら、ストアドプロシージャにすれば良いんじゃないですかね。負荷のオフロードができなくなるけど。
速度と言っても、レスポンスに対する要件がミリ秒を気にするほど本当にシビアなものなのかとか、実際にパフォーマンス計測やってモノ言ってるのかとか、「フォームのソースにクエリをベタ打ち」するレベルの人々が何言っても、はぁ…としか思えないのが本音ですが。
ちなみに
> 存じ上げませんでしたが、SQLを使わないという選択肢もあるのですね。
挙げてる手段は「SQLを使わない方法」ではなく（RDBMSを使う限りそんなものは存在しない）、「SQLを自分で書かない（自動生成SQLを利用する）」方法です。書いてないなら管理する必要ないから。
SQLに対する技術力に自信があるなら、自動生成結果に対して問題がある部分だけチューニングすればいいわけで、少なくとも「フォームにベタ書き」より「モダンな」作りにはなると思いますけど。
返信が大きく遅れてしまい、大変申し訳ありません。
私の理解していない根本の部分を解説頂けた気がしています。ありがとうございます。
>「フォームのソースにクエリをベタ打ち」するレベルの人々が何言っても、はぁ…としか思えないのが本音ですが。
→全くもって…。私も自分自身のスキルや、社内全体のスキルにため息しか出ません。
転職も勿論視野に入れますが、まずはここで出来る事を、と考えています。
>自動生成結果に対して問題がある部分だけチューニングすればいい
→実際にやってみました。だいぶと「モダン」に感じます。ありがとうございます。
SQLにこだわりがあるというよりは、SQL以外の選択肢が見えていない、という残念な状態でございまして…（笑）
笑ってもいられないので、日々努力してまいります。
ありがとうございましたm(_ _)m
0
質問が広範すぎるので、もう少し設計を固めて内容を絞った質問をした方が具体的な回答を得られると思います。とりあえず、フレームワークの概念的なものをある程度理解し、設計の指針を決める必要があります。
Webアプリケーション開発者から見た、MVCとMVP、そしてMVVMの違い
Webと書いてありますが、他のアプリケーションでも考え方は流用できる部分が多いです。
ソースにクエリが書いてあっても、ModelとViewをきちんと分離し、クラス・メソッドで機能が分けられているのであれば保守は難しくないと思いますが、フォームのソースにベタ書きとかだときついですね…いずれにせよ現環境で呼び出しているクエリと可変パラメータの分析が必要でしょう。ストアドは特別速度が要求されるとかじゃなければ、保守が割としんどいので手を出さない方が良いと思います。
投稿2021/01/20 08:15
編集2021/01/20 08:20
退会済みユーザー
総合スコア0
ご回答、ならびに、ご指摘ありがとうございます。
本当にレベルが低くて申し訳ないんですが、以下が自社の状況です。
→どのプログラムでも使うような機能について、最低限のものだけはdll化していますが、それ以外は全てフォームのソースに突っ込んでおり、radian様にご提示頂いたMVCという概念は欠片もない。
正直な所、自社以外のコードを読んだことがない（巷にあるサンプルコードはもちろん読んでいます。プロジェクトファイルの構成、より詳しく言えば、どういう場合には機能を分けて書いていくかを全くわかっていません。）為、「本来どうあるべきか」がわかっておらず、質問を絞れていない、という状態なのであろうと認識しています…。
>いずれにせよ現環境で呼び出しているクエリと可変パラメータの分析が必要でしょう。
→申し訳ありません…クエリと可変パラメータの分析というのは、具体的にどのような分析を行えばよいのでしょうか…差し支えなければご教授頂ければ幸いですm(_ _)m
>ストアドは特別速度が要求されるとかじゃなければ、保守が割としんどいので手を出さない方が良いと思います。
ありがとうございます。参考にさせて頂きます。
処理速度が要求されるケースもありますので、そういう場合だけ使うなどの切り分けを行っていきたいと思います。
> 正直な所、自社以外のコードを読んだことがない（巷にあるサンプルコードはもちろん読んでいます。プロジェクトファイルの構成、より詳しく言えば、どういう場合には機能を分けて書いていくかを全くわかっていません。）為、「本来どうあるべきか」がわかっておらず、質問を絞れていない、という状態なのであろうと認識しています…
時間が許すなら、書籍を読んだり既存のフレームワークを触ってみたり、ソースを読んだりして（実際に採用するかどうかは別）設計思想を理解したり、参考になる部分があれば真似してみたりするのが良いんでしょうけどね。一日にしてならずな部分なので、勉強するしかないです…
何にしても、何が問題で、それをこう修正する事で、このように改善される・こういうメリットがある、というのを自分の頭の中で具体的にイメージできて他人に説明出来ないと、実際に取り掛かるのは難しいと思います。
> クエリと可変パラメータの分析というのは、具体的にどのような分析を行えばよいのでしょうか…
そのままの意味です。全ての画面、バッチ処理単位でSQL処理をリストアップし、共通化可能な部分・廃止出来る部分等を検討します。どの程度置き換えや修正が必要なのかのボリュームも、ここでおおよそ見積もります。
ご返信ありがとうございます。
>時間が許すなら、書籍を読んだり既存のフレームワークを触ってみたり、ソースを読んだりして（実際に採用するかどうかは別）設計思想を理解したり、参考になる部分があれば真似してみたりするのが良いんでしょうけどね。一日にしてならずな部分なので、勉強するしかないです…
→そうですよね…。地道にやっていきたいと思います。
もしお心当たりがあれば、私のような人間に合うような書籍をお教え頂けないでしょうか。
必ず購入して読みます。
>何にしても、何が問題で、それをこう修正する事で、このように改善される・こういうメリットがある、というのを自分の頭の中で具体的にイメージできて他人に説明出来ないと、実際に取り掛かるのは難しいと思います。
→そうですね…。自分であれこれ検証しながらやっている所ですが…。説明できるまで落とし込んでいきたいと思います。
>そのままの意味です。全ての画面、バッチ処理単位でSQL処理をリストアップし、共通化可能な部分・廃止出来る部分等を検討します。どの程度置き換えや修正が必要なのかのボリュームも、ここでおおよそ見積もります。
→ありがとうございます。頓珍漢で理解できていませんでしたが、
（「クエリの管理」を考えるのなら、）いずれにせよ現環境で呼び出しているクエリと可変パラメータの分析が必要
という文脈だったようですね。理解しました。ありがとうございますm(__)m
あなたの回答
tips
プレビュー
