  |
検索画面のオプションの組み合わせごとに、ちょっとずつ違うSQLを、コピペしてちょっと変える手法で3万行に膨らませたプログラマな 売上レポートのプロとして重用されてたで
たとえばレコードが大量にあるコンビニの売上分析システム用のSQLはソースコードのサイズなんて気にしてらんないとおもう。 自分はDBはoracleしかしらないけど「SQLを解析して実行用のS...
共通部分と変化する部分が、最初に作った本人にしかわからず他の誰も触れないのが問題なんやで
わかんない。共通部分と変化する部分？
コピペしてちょっと変える ってことは大部分が共通で、少しだけ違う、ってことやがな
データベースの内部処理的には大事ですね。
コピペで作るかどうかが?
コピペは手段ですが、大事なんです。オラクルでいうと実行計画とかに関係しますので。
んー、同じ意味のSQLでも大文字か小文字かの違いでキャッシュされないみたいな話を、コピペの正当化に使ってる輩かな
業種しりたいんだよな、売上っていってるけど。
業種関係ないんだよな キャッシュのために同じ意味のSQLは同じ文字列にするべき、って話なら、共通のテンプレートにするべきで、コピペにするべきじゃないし 元増田は、検索条件によ...
パラメータを含むSQLわかるか？
デー多量やデータ分布がかわるとSQLもかわるやろ。業種をきいたのはそれ。たとえば個人商店とコンビニはちがう。
オラクルだと実行計画つくる時点でSQL部分はキャピタルに変換されるので影響ないですね。
パラメータなのか構文なのか気になる。
それも見比べなければわからない
元の質問者は理解できないと思う。
ただSQLの性能を考えると悪いとも思えない。
関係ないで
実行計画を作る回数や最適な実行計画を選択する（あやまった実行計画を選択するリスクを避けるとも言える）可能性は高まるのかなーと思った。
いたずらにランダムなSQLが発行される仕組みよりは？と考えたのかね。データ量による。
売上レポートはわりあいリアルタイムに見たいでーって上の人間は多いから、SQLを小分けにして実行計画や検索結果をキャッシュさせとくってはあり得るんじゃないか。と思ったり。
SQLを小分けにして部品化してるならええやで 検索オプションが増える度に、if文の枝を増やす、SQLをまるごとコピペしてちょっとだけ変える、その繰り返しの3万行やで ここでは誰も反発...
こういう質問しとくだけしといて意見返してくれないやつ、なんなんだ？
ぶん殴りたくなるよな 俺もそうだ 今までいろんなことで説明してやっても 何の例もなく音沙汰なしのクソ野郎ばかりだった
動けば正義 ちなみに王道は札束でインフラを殴る、な。
その手のって今はBIツールで自動生成しない？ あとSQLのトータルの行数が増えたところでどうでもよくね？ それにその手の分析系のSQLってせいぜい日に数回しか実行されないのであれば...
30
