SQLなら俺に訊け [無断転載禁止]©2ch.net
>>197
無駄なソートはRDBMSによっては致命的な性能問題を引き起こす。 >>198
「無駄な」ソートはな
order by 書けば絶対ソートするとでも思ってるんだろうか
つかおまえソートしない方法提示できてないだろ
テーブルスキャン何回もやるぐらいならソート1回のほうがましなことも多いぞ
まあなんにせよインデックス構成とオプティマイザ次第だけどな TOP/LIMIT/FETCH FIRST + ORDER BY使ったtop-Nクエリが
相関サブクエリ使ったtop-Nクエリより遅くなるようなメジャーなDBMSがあるの? 内部の処理の説明をSQLの構文で説明するのは、知識がなさすぎると思うぞ。
少なくとも業務システムでは嫌われる。 構文の話してるヤバい奴ってどれ?
というか、こういうどこに向かって話してるのかわからないようなのもなんかヤバい。 つかDB板の連中って何でそれが重い処理なのかまるで理解してないよね
しかも呼び出し側含めた全体最適化なんてする気もないようだし、
あいつらはSQLを手打ちでもしてるのだろうか? まるですでに重いと決まっているかのような物言い。これはヤヴァイ。 インデックスを張ってる状態での189は間違いなく軽い
DB屋はDBで済ませる傾向があるとは聞くし、
クエリプランナで最高に最適化されてリングバッファ的に動くのなら196も確かに軽いが、
そうならない場合は糞重い
俺はそこまでDBのことは知らないので、
189が第一選択肢で、速度の問題があればインデックスを張る
これで問題がある場合は、自前でカーソルをとってリングバッファを実装する
DB屋なら196がそれぞれのDBで軽いか重いか把握した状態で使うのだとは思う
ただそれは俺らプログラマとはだいぶ視点が違うと感じた ソートの話は相関サブクエリを使えという話じゃなく
指定日以前の任意の3レコードなのか(ソート無し)
指定日以前の直近の3レコードなのか(ソート有り)
という違いを指摘したかったんでしょ それもあるとは思ったが、187だとほぼid通りの順なのだろうし、
191で文句も言ってないので、おそらくログ的な物のラスト3行を取りたいのだろうよ
なら俺は208で言ったとおりにする
(なお俺は189ではない)
それを(実際どうなるのかは知らんが)糞遅くなりそうなSQLを出すのもいかがなものかと
質問者が悪いと言えばそうだが、
質問者のレベル推定も含めての回答にしないと、ここでは成り立たない
「ソートして良い」と勝手に決めるのが問題なら、
「ソートしてはいけない」と勝手に決めるのもまた問題でしかない
なら聞けばいいのに、それもしない
(なお、しても意味は通じず、余計に面倒になるのは見えているので、
今回のようにいきなり189で問題ないとも思うが)
なんというか、この辺の空回り具合は、文化の違いを俺は感じたよ
ただまあ俺らが特殊なのかもしれないけどな
この板では基本的にエスパー出来ないと回答は無理だし SQLで4桁文字列'hhmm'とDatetime型を結合する方法って分かる?
例:
’1234’ char型
’2022/07/12 00:00:000’ datetime型 があったときに、
↓
2022/07/12 12:34:000 datetime型 みたいに結合したいんだけど。。 とりあえず'1234'を12と34の数字にして、元の日付に12時間と34分を足せばいいんじゃねふ
日付まわりはDBMSによって違うから
日付時刻をサポートしてるDBMSなら指定の時間、分を足す関数かなんかがあるだろうからそれ調べて使え >>211
普段、日時の計算をどうやっているのか、むしろ疑問ですね。
古い本でいいから古本を買えよ! 複数のselect count(※)を1つのファイルに出力する方法教えてください。。 SQLで急にファイル出力とか言われても何のこっちゃ分からんわ
シェルスクリプトで普通にappendでもしろや explain analyzeを付けると1秒、付けないと30秒かかるクエリがあるのですが一般的には何が原因なのでしょうか >>220
両方同じようにクエリが実行されてるのなら
結果セットの転送コストがめちゃくちゃ大きいんじゃないの? SQL Server 2022 正式リリース(米国11/16日)
MSDNダウンロードサイトでDeveloper EditionのISOリリースを確認 phpMyAdmin使ってます。
型が合わないデータの入力があったとき、
拒否するか、無理やりデフォルトの値を登録するか。
それを設定するコンパネとかありますか? ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数って言われてるけど普通にRETURNできるやん
歴史的な背景でもあるんか
それとも解説者か俺があほなんか >>224
一部のDBMSの古いバージョンではOUT/INOUT引数を使わないと値を返せなかったんだよ >>224
それはファンクション(関数)とストアドプロシージャの違いがあまりないDBMSの場合 ファンクションは戻り値があるプロシージャという意味 VBもAda言語もそうだけど、ファンクションプロシージャとサブプロシージャをわけているのは、プログラミング言語ではめずらしくない。
C言語、C言語に影響を受けた言語だと、わざわざ戻り値なしをvoidと書いて明確にする。
ファンクションは戻り値を利用するもの。戻り値を呼び出し側が無視できる仕様かどうかの問題。 SQL標準的にはプロシージャに戻り値があるかどうかはimplementation defined
戻り値があったほうが便利なので多くのDBMSベンダーはscalar valueとresult setのどちらも返せるようにしてる
一方(ストアド)ファンクションはSQL標準で戻り値が必須でscalar valueのみと定められている
プログラミング言語でファンクションとプロシージャを区別してたのは太古の昔の話
今ではもうそんな区別に価値はなくなってる
SQL標準で区別されてるのは利用方法や利用する場所が基本的に違うため MySQL系はファンクションだと、COMMITなどのトランザクション制御ができないので、あまり考えずにファンクションで統一などしてはならない。 >>233
前半と後半で違う説明をしているね。
ファンクションは「関数」だ。
OUTパラメータを参照するのは「手続き」という処理だ。
プロシージャで戻り値とOUTパラメータを返す場合は、ちゃんと仕様書がないとわけのわからないものになる。 そもそも、DBMSの指定や前提もなく
>ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数
とか書いてあるなら、そのサイトに問題があるだけの話
まあ、ちゃんと前提を読んでないか理解してない読み手の問題の可能性もあるが 関数やプロシージャのことを「メソッド」と書いている書籍もあるくらいだからな。勝手な名前をつけるやつはたくさんいる。 ざっくり言うと
ファンクションは1つのSQL文の中でSELECT句やWHERE句などの一部として繰り返し利用する機能を定義したもの
プロシージャはSQL文を使ったひとまとめの処理をSQL文の一部としてではなく外部から繰り返し呼び出せるように定義したもの
これが最も根本的な違い
ファンクションでトランザクション制御しようと考えてしまったりデータベースを更新しようと考えてしまう人はこの根本的違いを理解してない そもそもプロシージャは手続きという処理という意味で、ファンクション(関数)は機能という結果を返す処理の意味。 全然違う
またいい加減なことを言って振り出しに戻すのやめろ ファンクションプロシージャは結果を戻り値で返す
サブプロシージャはOUTパラメータ(引数)で返す
SQLの関数は関数(ファンクションプロシージャ)で実装しないとSQLの構文が破綻する >>241
だから、オラクル社はAda言語をそのまま流用しただけだよ。
ANSIはファンクションの方を先に標準SQLに組み込んだだけ。
ファンクションとサブを区別しているかどうかは、Ada言語を踏襲しているかどうかの違い。
C言語のように戻り値を無視する構文がいいのか悪いのかという話だよ。 perl の戻り値の仕組みは面白いと思ったのは古い思い出 noSQLのスレはないの
オブジェクト指向データベースとかはsql使うのかな