SQLなら俺に訊け [無断転載禁止]©2ch.net

**デフォルトの名無しさん** · 2017/07/14(金) 07:40:53.63

さあ

**デフォルトの名無しさん** · 2021/12/24(金) 19:31:42.64

お早い回答ありがとう。
もっと色々試すが取り急ぎ。

新案1：
SELECT CASE WHEN col0 LIKE 'str' THEN 0 WHEN col1 LIKE 'str' THEN 1 ELSE -1 END AS col,target FROM sometable WHERE col>=0;
explainでは32、他だと文法エラーらしいがSQLiteだと通る。(参考 https://rainbow-engine.com/sql-howto-caseresult-where/)
explain query plan では
0|0|0|SCAN TABLE tags_bulk VIRTUAL TABLE INDEX 0:

新案2：
SELECT col,target FROM (SELECT CASE WHEN col0 LIKE 'str' THEN 0 WHEN col1 LIKE 'str' THEN 1 ELSE -1 END AS col,* FROM sometable) WHERE col>=0;
他ではこう書けと言われているもの。
explainでは32で、見た目中身も同じ。explain query plan も全く同じ。

**デフォルトの名無しさん** · 2021/12/24(金) 19:32:06.67

元：
SELECT 0,target FROM sometable WHERE col0 MATCH 'str' UNION SELECT 1,target FROM sometable WHERE col1 MATCH 'str' AND col0 NOT MATCH 'str';
explainでは同じく32だが、見た目は違う。が、読み方が分からない。
explain query planでは以下。見た目通り2周している。
1|0|0|SCAN TABLE sometable VIRTUAL TABLE INDEX 9:
2|0|0|SCAN TABLE sometable VIRTUAL TABLE INDEX 11:
0|0|0|COMPOUND SUBQUERIES 1 AND 2 USING TEMP B-TREE (UNION)

MATCHはCASEの中では使えないらしくLIKEにしている。
(Error: unable to use function MATCH in the requested contextと出る。)
MATCHだとインデックスが使える分速いはずだが2周する分遅くなるのでどうなるか。

DBやアプリ構造の改善案は今のところ思いつかない。(変更は可能)
カラムはそれぞれ別の管理なので、先に合わせる事は出来ない。

**デフォルトの名無しさん** · 2021/12/24(金) 21:34:31.41

新案3: UNION ALL
SELECT 0,target FROM sometable WHERE col0 MATCH 'str' UNION ALL SELECT 1,target FROM sometable WHERE col1 MATCH 'str' AND col0 NOT MATCH 'str';
元はUNIONにB-TREEが必要でこの分無駄だった。
explainは23と軽くなった。explain query plan は以下。
1|0|0|SCAN TABLE sometable VIRTUAL TABLE INDEX 9:
2|0|0|SCAN TABLE sometable VIRTUAL TABLE INDEX 11:
0|0|0|COMPOUND SUBQUERIES 1 AND 2 (UNION ALL)
単発で別々にクエリすればUNION ALL 分も取れるが、単に追加してるだけなのでPHP側で結合するよりは速いはず。

今のところこの辺か。他に何かあればよろしく。
とりあえず実装して試すが、差が出るほどDBの中身が埋まるまでにはだいぶかかるとは思う。

**デフォルトの名無しさん** · 2021/12/24(金) 21:37:57.02

>>157
その案はどちらもテーブルスキャンになってインデックス使わない
SELECT句のCASE式とは別にWHERE句に本来の条件を書く

DB構造の話はカラムとして持つべきデータじゃなくて
子テーブルの行として持つべきデータかと思ったんだけど
全文検索でいずれかのカラムに検索キーワードが含まれてる行を
どのカラムかという情報も含めて抽出する用途なんであれば
そのままでいいんじゃないかと思う

**デフォルトの名無しさん** · 2021/12/24(金) 22:28:50.21

>>160
> その案はどちらもテーブルスキャンになってインデックス使わない
そうだが、今回はこれで仕様的にも問題ない。

俺が勘違いしてたのもあって言葉が混乱しているが、
SQLiteのFTSは全文検索仕様で、通常のインデックスは作成出来ない。
FTSで「インデックス」と言われてるのは全文検索用のキーワードインデックスで、
つまりMATCHがLIKEに比べて糞速いだけで、常に全row検索する仕様のようだ。
https://sqlite.org/fts3.html
（俺がFTSの「インデックス」をここでもそのままインデックスと表記したのが不味かった。
FTS用のテーブルでは通常のインデックスでの単rowからの検索は出来ない。
《rowidだけは使えるらしいが、使っても explain query plan では scan と表示された》)

> 子テーブルの行として持つべきデータかと思ったんだけど
あーなるほど、勘がいいね。
実は元々そういう構造になっていたのだが、
下部構造のサマリを作ってしまった方が楽だからそうしようとしていて、
col0は上部から与える名前、col1は下部のそれぞれの中身の寄せ集めになってる。
だからcol0を下部構造の各行のcol1相当部分に対して混ぜ込めば、下部構造で一発クエリ出来る。
そして元々そうしていたのだが、他の都合上、管理が面倒なので変更しようとしているところ。
しかしよく分かったね。まあ妙な事をしてるからか？

まあとにかくありがとう。
今回は下部構造のサマリなので、常に全文検索で問題ない。
言葉が混乱しててごめん。

**デフォルトの名無しさん** · 2021/12/25(土) 19:58:56.64

NOT MATCH が使えない。(Error: unable to use function MATCH in the requested context)
ただし動的エラーで、2つ目のクエリでcol1にMATCHの後、col0にNOT MATCHのチェックで落ちるようだ。
CASEの中でも使えないし、やはりMATCHはインデックスのようだ。
ところでMATCH NOTは使える。

新案4: MATCH NOT
SELECT 0,target FROM sometable WHERE col0 MATCH 'str' UNION ALL SELECT 1,target FROM sometable WHERE col1 MATCH 'str -col0:str';
これでexplainは20、explain query plan は以下。
1|0|0|SCAN TABLE sometabke VIRTUAL TABLE INDEX 9:
2|0|0|SCAN TABLE sometable VIRTUAL TABLE INDEX 11:
0|0|0|COMPOUND SUBQUERIES 1 AND 2 (UNION ALL)

当面はこの新案4で行く予定。

**デフォルトの名無しさん** · 2022/05/10(火) 17:48:54.08

メモ＆報告
SQLModelにてRelationshipsがうまく機能しなかったが
結論としてSQLAlchemyのバージョンを変更したらうまくいった
https://github.com/tiangolo/sqlmodel/issues/327#issuecomment-1116983382
他のバージョンは試してないが
pip install SQLAlchemy==1.4.17
でいけた
#python #SQLModel

**デフォルトの名無しさん** · 2022/05/28(土) 08:36:34.97

カーソルって何のために使うの？

**デフォルトの名無しさん** · 2022/05/28(土) 11:06:08.08

iteration

**デフォルトの名無しさん** · 2022/05/28(土) 12:02:17.61

>>164
クライアント側に結果セットを全部抱えなくてもいいのと、クエリが全部終わらなくても出てきたレコードから順に
処理を進められるんで、主に対象のレコードが多いバッチ処理なんかで使う。

**デフォルトの名無しさん** · 2022/05/28(土) 16:19:02.25

SQLでDECLARE CURSORと書くサーバーサイドのカーソルと
DBドライバーのAPIが提供するクライアントサイドのカーソルは別のもの

前者はSQLで1行単位の処理をしたい場合に使うものだけどよほど特殊な事情がない限りは使わない

後者はクライアントがクエリの結果セットを塊単位でフェッチするのに使うもので呼び名が違うこともあるが一般的に使われてる

どちらも結果セット内の次の読み込み位置を指し示す抽象オブジェクトとしての役割は同じ

**デフォルトの名無しさん** · 2022/06/07(火) 20:12:44.49

車テーブルがあって
車両番号　走行日　走行距離(出発)　走行距離(到着)　　運転手
というカラムがあります。

各車両の現在の走行距離と、今運転手が乗っていれば運転手名が欲しいです。
乗っているという判断は
走行距離(出発)が入ってるけど到着は入ってない、という事になってます。

これってMAX関数で現在の走行距離とるクエリと、運転手データとるクエリとでJOINするしかないですよね？

**デフォルトの名無しさん** · 2022/06/07(火) 22:18:49.63

>>168
DBMSによる
DB板で聞くといい

**デフォルトの名無しさん** · 2022/06/08(水) 02:38:50.06

>>168
普通にCASEで行けそうだけど

現在の走行距離とは何？
運転手が乗ってなければどうしたいの？

**デフォルトの名無しさん** · 2022/06/08(水) 04:53:57.00

GROUP BYの集計項目以外のカラムの値(運転手等)をサブクエリ使わずに一発でできるかどうかという質問かと思ったが
運転手を表示する場合としない場合の分岐方法の話ならCASE式だね

**168** · 2022/06/08(水) 05:07:53.00

>>171
そういう意図でした！
caseでもう一度試行錯誤してみます！

**168** · 2022/06/08(水) 05:13:05.52

>>170
現在の運転手がいなかったらnullにしたいです。

**168** · 2022/06/08(水) 19:01:35.68

>>168
解決しました！ありがとうございます！

**デフォルトの名無しさん** · 2022/06/14(火) 14:33:53.86

SQL Serverで質問です。

テーブル1
テーブル2
テーブル3
テーブル4
…
とテーブルはどんどん増えます。

各テーブルにはIDという数値型のフィールドがあるのですが、
テーブル名とIDの最大値の一覧表にしたいです。

INFORMATION_SCHEMAを使ってテーブル名の一覧までは出せたのですが、
それらの各IDの最大値を産出するのはどう書けばいいのでしょうか？

**デフォルトの名無しさん** · 2022/06/14(火) 15:30:50.28

>>175
identity columnなら
SELECT IDENT_CURRENT (‘table_name’)かsys.identity_columnsのlast_value
違うなら
SELECT MAX(ID) FROM table_name

**デフォルトの名無しさん** · 2022/06/14(火) 16:44:05.01

>>176 ありがとうございます。

しかしながら

テーブル名　IDの最大値
テーブル1　6
テーブル2　1014
テーブル3　1990
テーブル4　74
テーブル5　1861
テーブル6　136

という感じに表示されてほしいです

**デフォルトの名無しさん** · 2022/06/15(水) 20:45:45.59

一つのテーブルに対して、複数のクエリ（参照、更新）が同時に投げられても、テーブルロックされない限り並行して動くものなの？

**デフォルトの名無しさん** · 2022/06/17(金) 01:53:08.02

>>178
ロックはテーブルロックだけじゃないし
同時実行できるかはハードやDBMSの機能によるんだが
まあ基本的には複数のコネクションのクエリは並列して動くと考えていいんじゃね

**デフォルトの名無しさん** · 2022/06/22(水) 21:18:18.43

>>177
それなら統計情報を検索すればいい話

**デフォルトの名無しさん** · 2022/06/29(水) 17:50:51.99

全く同じクエリの処理してるのに、時間帯によって波があるのって何が原因かな？
夜中は１０秒、朝９時くらいは1時間とかザラにある
しかも、毎日波がある
こんなに気まぐれなの?

**デフォルトの名無しさん** · 2022/06/29(水) 18:45:17.79

>>181
そんな情報だと時間帯によって何かが変化してるとしか言えない
頑張って

**デフォルトの名無しさん** · 2022/06/29(水) 18:51:34.33

>>182
情報が欲しいなら、お願いしてみれば？

**デフォルトの名無しさん** · 2022/06/29(水) 18:59:48.80

情報はタダじゃねえんだよ

**デフォルトの名無しさん** · 2022/06/29(水) 21:10:29.16

10秒と1時間越えで何が原因かあたりもつけられないってかなりヤバない？

**デフォルトの名無しさん** · 2022/06/29(水) 21:18:34.19

マシンのメモリなどの、何かのリソースが少ないのかも

例えばメモリが少ないと、1クリックしてから処理されるまで、1分掛かる。
遅すぎて何もできない

**デフォルトの名無しさん** · 2022/06/30(木) 16:46:00.43

バラバラな日付が入っているテーブルから、
特定日以前3日間のレコードを取るSQL教えてください

hogeテーブル
id,date
5,2022-06-30
4,2022-06-19
3,2021-12-24
2,2021-06-03
1,2021-01-02

ここから2022-06-19以前の3日間のレコード
2022-06-19
2021-12-24
2021-06-03
を取りたいです

**デフォルトの名無しさん** · 2022/06/30(木) 17:49:50.05

その日付より小さくて、その日付ー３日より大きいっていうwhere条件書くだけだと思うが

日付の扱いはＤＢＭＳによって差が大きいからこれ以上はちゃんと環境書け

**デフォルトの名無しさん** · 2022/06/30(木) 17:56:20.31

>>187
where date <= ‘2022-06-19’
order by date desc
limit 3;

上から3行取る方法はDBMSによって違うのでマニュアルを読んで

**デフォルトの名無しさん** · 2022/06/30(木) 18:54:13.55

>>189
ソートしろとは言ってないぞ

**デフォルトの名無しさん** · 2022/06/30(木) 19:51:26.35

>>188
その日付ー３日は、
日付がバラバラなのでできません

>>189
これでできそうです
ありがとうございます

**デフォルトの名無しさん** · 2022/06/30(木) 20:18:37.20

ああ、三日じゃなくて３件分のデータが欲しいのか
日付にダブりがないなら>>189さんの方法で
ダブりがあるならdistinctなりgroup byなりしてからだな

>>190
ソートしないでできるならぜひその方法を教えてくれ

**デフォルトの名無しさん** · 2022/06/30(木) 20:29:12.21

>>192
ソートする必要がどこにあるのか？

**デフォルトの名無しさん** · 2022/06/30(木) 20:31:30.23

3日が3レコードという意味なのかどうかからわからない。

**デフォルトの名無しさん** · 2022/06/30(木) 21:19:29.49

>>192
自分より大きくて指定日付以下であるレコードが3件未満となるものを選ぶ。

**デフォルトの名無しさん** · 2022/06/30(木) 22:57:01.80

>>195
なるほど。件数がゼロ件になるやつの考慮がいるけど、いけるのはいけそうだな
SELECT * FROM hoge T WHERE
　(SELECT count(*) FROM hoge
　　WHERE hoge.[date] >t.date AND hoge.[date]<='2022-06-19'
　) < 3 AND t.[date]<='2022-06-19'
こんな感じか
これならオフセット取れないとかwindow関数使えないDBとかでも動くな

**デフォルトの名無しさん** · 2022/06/30(木) 23:12:15.50

>>190
ソートしろと言われているのにソートしないのは問題だが逆に
ソートしろと言われてないのにソートするのは構わんだろ

**デフォルトの名無しさん** · 2022/07/01(金) 00:36:44.48

>>197
無駄なソートはRDBMSによっては致命的な性能問題を引き起こす。

**デフォルトの名無しさん** · 2022/07/01(金) 03:40:55.11

>>198
「無駄な」ソートはな
order by 書けば絶対ソートするとでも思ってるんだろうか
つかおまえソートしない方法提示できてないだろ

テーブルスキャン何回もやるぐらいならソート１回のほうがましなことも多いぞ
まあなんにせよインデックス構成とオプティマイザ次第だけどな

**デフォルトの名無しさん** · 2022/07/01(金) 09:55:27.56

TOP/LIMIT/FETCH FIRST + ORDER BY使ったtop-Nクエリが
相関サブクエリ使ったtop-Nクエリより遅くなるようなメジャーなDBMSがあるの？

**デフォルトの名無しさん** · 2022/07/02(土) 00:59:29.77

構文の話をし始めるやつはヤバい

**デフォルトの名無しさん** · 2022/07/02(土) 09:03:05.11

構文の話は誰もしてない・・・よね？

**デフォルトの名無しさん** · 2022/07/02(土) 19:31:42.58

内部の処理の説明をSQLの構文で説明するのは、知識がなさすぎると思うぞ。

少なくとも業務システムでは嫌われる。

**デフォルトの名無しさん** · 2022/07/02(土) 20:23:17.28

構文の話してるヤバい奴ってどれ？

というか、こういうどこに向かって話してるのかわからないようなのもなんかヤバい。

**デフォルトの名無しさん** · 2022/07/02(土) 21:48:05.38

これDB板によく湧くヤバいやつだわ
そっ閉じ推奨

**デフォルトの名無しさん** · 2022/07/03(日) 12:56:59.34

つかDB板の連中って何でそれが重い処理なのかまるで理解してないよね
しかも呼び出し側含めた全体最適化なんてする気もないようだし、
あいつらはSQLを手打ちでもしてるのだろうか？

**デフォルトの名無しさん** · 2022/07/03(日) 21:52:19.27

まるですでに重いと決まっているかのような物言い。これはヤヴァイ。

**デフォルトの名無しさん** · 2022/07/03(日) 22:24:10.66

インデックスを張ってる状態での189は間違いなく軽い
DB屋はDBで済ませる傾向があるとは聞くし、
クエリプランナで最高に最適化されてリングバッファ的に動くのなら196も確かに軽いが、
そうならない場合は糞重い

俺はそこまでDBのことは知らないので、
189が第一選択肢で、速度の問題があればインデックスを張る
これで問題がある場合は、自前でカーソルをとってリングバッファを実装する

DB屋なら196がそれぞれのDBで軽いか重いか把握した状態で使うのだとは思う
ただそれは俺らプログラマとはだいぶ視点が違うと感じた

**デフォルトの名無しさん** · 2022/07/03(日) 23:34:25.47

ソートの話は相関サブクエリを使えという話じゃなく
指定日以前の任意の3レコードなのか(ソート無し)
指定日以前の直近の3レコードなのか(ソート有り)
という違いを指摘したかったんでしょ

**デフォルトの名無しさん** · 2022/07/04(月) 01:22:49.55

それもあるとは思ったが、187だとほぼid通りの順なのだろうし、
191で文句も言ってないので、おそらくログ的な物のラスト3行を取りたいのだろうよ

なら俺は208で言ったとおりにする
(なお俺は189ではない)
それを(実際どうなるのかは知らんが)糞遅くなりそうなSQLを出すのもいかがなものかと

質問者が悪いと言えばそうだが、
質問者のレベル推定も含めての回答にしないと、ここでは成り立たない

「ソートして良い」と勝手に決めるのが問題なら、
「ソートしてはいけない」と勝手に決めるのもまた問題でしかない
なら聞けばいいのに、それもしない
（なお、しても意味は通じず、余計に面倒になるのは見えているので、
今回のようにいきなり189で問題ないとも思うが）
なんというか、この辺の空回り具合は、文化の違いを俺は感じたよ

ただまあ俺らが特殊なのかもしれないけどな
この板では基本的にエスパー出来ないと回答は無理だし

**デフォルトの名無しさん** · 2022/07/12(火) 22:08:19.53

SQLで４桁文字列'hhmm'とDatetime型を結合する方法って分かる？

例：
’1234’ 　char型
’2022/07/12 00:00:000’ datetime型　があったときに、
　　↓
2022/07/12 12:34:000　　datetime型　みたいに結合したいんだけど。。

**デフォルトの名無しさん** · 2022/07/12(火) 23:46:03.19

とりあえず'1234'を12と34の数字にして、元の日付に12時間と34分を足せばいいんじゃねふ

日付まわりはDBMSによって違うから
日付時刻をサポートしてるDBMSなら指定の時間、分を足す関数かなんかがあるだろうからそれ調べて使え

**デフォルトの名無しさん** · 2022/07/13(水) 13:38:16.35

https://wandbox.org/permlink/TWt0aMILwOZlhQwu
front-page.phpのPHPとarchive.phpのSQLをつなげたいのですが、コンテンツが何も表示されません。
どうすればよいのでしょうか…

※参考サイト
https://cosybench.com/customize-wp-archives-look/

**デフォルトの名無しさん** · 2022/07/13(水) 16:51:17.49

変数設定が抜けておりました

**デフォルトの名無しさん** · 2022/07/13(水) 20:55:05.36

>>211
関数

**デフォルトの名無しさん** · 2022/07/15(金) 12:26:52.71

>>211
普段、日時の計算をどうやっているのか、むしろ疑問ですね。

古い本でいいから古本を買えよ！

**デフォルトの名無しさん** · 2022/07/25(月) 21:13:25.51

複数のselect count(※)を1つのファイルに出力する方法教えてください。。

**デフォルトの名無しさん** · 2022/07/25(月) 22:10:59.17

SQLで急にファイル出力とか言われても何のこっちゃ分からんわ
シェルスクリプトで普通にappendでもしろや

**デフォルトの名無しさん** · 2022/07/28(木) 20:47:41.93

ネタに反応すんな

**デフォルトの名無しさん** · 2022/11/10(木) 10:38:00.26

explain analyzeを付けると１秒、付けないと30秒かかるクエリがあるのですが一般的には何が原因なのでしょうか

**デフォルトの名無しさん** · 2022/11/10(木) 12:15:12.96

>>220
両方同じようにクエリが実行されてるのなら
結果セットの転送コストがめちゃくちゃ大きいんじゃないの？

**デフォルトの名無しさん** · 2022/11/17(木) 10:16:58.88

SQL Server 2022 正式リリース(米国11/16日)
MSDNダウンロードサイトでDeveloper EditionのISOリリースを確認

**デフォルトの名無しさん** · 2023/02/12(日) 18:13:43.26

phpMyAdmin使ってます。
型が合わないデータの入力があったとき、
拒否するか、無理やりデフォルトの値を登録するか。
それを設定するコンパネとかありますか？

**デフォルトの名無しさん** · 2023/08/25(金) 10:09:06.20

ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数って言われてるけど普通にRETURNできるやん
歴史的な背景でもあるんか
それとも解説者か俺があほなんか

**デフォルトの名無しさん** · 2023/08/25(金) 14:00:50.18

論理演算が弱すぎる

**デフォルトの名無しさん** · 2023/08/25(金) 18:18:42.69

>>224
一部のDBMSの古いバージョンではOUT/INOUT引数を使わないと値を返せなかったんだよ

**デフォルトの名無しさん** · 2023/08/30(水) 22:18:57.94

>>4
全列ｎｕｌｌでも？

**デフォルトの名無しさん** · 2023/08/31(木) 14:07:47.09

>>224
それはファンクション(関数)とストアドプロシージャの違いがあまりないDBMSの場合

**デフォルトの名無しさん** · 2023/08/31(木) 14:16:19.77

ファンクションは戻り値があるプロシージャという意味

**デフォルトの名無しさん** · 2023/08/31(木) 14:31:41.51

違う
それは特定ベンダーの勝手な解釈

**デフォルトの名無しさん** · 2023/08/31(木) 15:20:59.08

元はユーザー定義関数

**デフォルトの名無しさん** · 2023/08/31(木) 15:26:10.21

VBもAda言語もそうだけど、ファンクションプロシージャとサブプロシージャをわけているのは、プログラミング言語ではめずらしくない。

C言語、C言語に影響を受けた言語だと、わざわざ戻り値なしをvoidと書いて明確にする。

ファンクションは戻り値を利用するもの。戻り値を呼び出し側が無視できる仕様かどうかの問題。

**デフォルトの名無しさん** · 2023/08/31(木) 16:29:25.54

SQL標準的にはプロシージャに戻り値があるかどうかはimplementation defined
戻り値があったほうが便利なので多くのDBMSベンダーはscalar valueとresult setのどちらも返せるようにしてる
一方(ストアド)ファンクションはSQL標準で戻り値が必須でscalar valueのみと定められている

プログラミング言語でファンクションとプロシージャを区別してたのは太古の昔の話
今ではもうそんな区別に価値はなくなってる
SQL標準で区別されてるのは利用方法や利用する場所が基本的に違うため

**デフォルトの名無しさん** · 2023/08/31(木) 16:31:16.87

MySQL系はファンクションだと、COMMITなどのトランザクション制御ができないので、あまり考えずにファンクションで統一などしてはならない。

**デフォルトの名無しさん** · 2023/08/31(木) 16:41:03.73

>>233
前半と後半で違う説明をしているね。

ファンクションは「関数」だ。

OUTパラメータを参照するのは「手続き」という処理だ。

プロシージャで戻り値とOUTパラメータを返す場合は、ちゃんと仕様書がないとわけのわからないものになる。

**デフォルトの名無しさん** · 2023/08/31(木) 18:27:10.59

なんだこの中身のないアホなレスはw

**デフォルトの名無しさん** · 2023/08/31(木) 23:06:43.05

そもそも、ＤＢＭＳの指定や前提もなく
>ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数
とか書いてあるなら、そのサイトに問題があるだけの話

まあ、ちゃんと前提を読んでないか理解してない読み手の問題の可能性もあるが

**デフォルトの名無しさん** · 2023/09/01(金) 20:37:48.72

関数やプロシージャのことを「メソッド」と書いている書籍もあるくらいだからな。勝手な名前をつけるやつはたくさんいる。

**デフォルトの名無しさん** · 2023/09/01(金) 23:32:50.20

ざっくり言うと
ファンクションは1つのSQL文の中でSELECT句やWHERE句などの一部として繰り返し利用する機能を定義したもの
プロシージャはSQL文を使ったひとまとめの処理をSQL文の一部としてではなく外部から繰り返し呼び出せるように定義したもの
これが最も根本的な違い

ファンクションでトランザクション制御しようと考えてしまったりデータベースを更新しようと考えてしまう人はこの根本的違いを理解してない

**デフォルトの名無しさん** · 2023/09/02(土) 22:12:45.21

そもそもプロシージャは手続きという処理という意味で、ファンクション(関数)は機能という結果を返す処理の意味。

**デフォルトの名無しさん** · 2023/09/02(土) 23:45:29.35

全然違う
またいい加減なことを言って振り出しに戻すのやめろ

**デフォルトの名無しさん** · 2023/09/16(土) 22:45:43.61

数学がわからないんだろ

**デフォルトの名無しさん** · 2023/09/16(土) 22:48:52.44

ファンクションプロシージャは結果を戻り値で返す

サブプロシージャはOUTパラメータ(引数)で返す

SQLの関数は関数(ファンクションプロシージャ)で実装しないとSQLの構文が破綻する

**デフォルトの名無しさん** · 2023/09/16(土) 22:55:55.12

>>241
だから、オラクル社はAda言語をそのまま流用しただけだよ。

ANSIはファンクションの方を先に標準SQLに組み込んだだけ。

ファンクションとサブを区別しているかどうかは、Ada言語を踏襲しているかどうかの違い。

C言語のように戻り値を無視する構文がいいのか悪いのかという話だよ。

**デフォルトの名無しさん** · 2023/09/17(日) 13:55:16.79

perl の戻り値の仕組みは面白いと思ったのは古い思い出

**デフォルトの名無しさん** · 2023/09/17(日) 23:44:17.06

noSQLのスレはないの
オブジェクト指向データベースとかはsql使うのかな

**デフォルトの名無しさん** · 2023/09/18(月) 11:28:48.80

noSQLスレは以前はあった

**デフォルトの名無しさん** · 2023/10/06(金) 19:29:28.75

>>246
データベース板を忘れないでください

**デフォルトの名無しさん** · 2024/04/15(月) 01:05:12.02

入門レベルです
環境はsqliteをsqlite3 CLIを通して使ってます

expr(式)を評価して簡易に値を確かめる方法はあったりしませんかね？
目的は学習目的の挙動把握実験と切り分けデバッグです、例えば'foo' LIKE 'f_%'とかそんなやつを試したい

sqlで実行できるのはstmt(文)のみなので、今のところexprを受け付ける何らかのstmt(文)に組み込み、その結果から値を間接的に類推してます
類推するにせよ、そもそもstmt毎に固有の意味論があるゆえ、一貫した振る舞いも得られず
なかなかしんどいです…

それっぽいCLIコマンドの.printも、シグネチャが.print STRING+なのでexpr評価がされませんし

**デフォルトの名無しさん** · 2024/04/15(月) 11:17:52.57

>>249
> % 　0文字以上の任意の文字列
> _ 任意の1文字
> [^] 除外
> https://techmania.jp/blog/sql-like/
正規表現と違い、これだけしかないのに要らないだろ。
お前は 1+1 と打って 2 と出る環境がないと死ぬ人か？

(昨今の文系馬鹿が流入してきてる)プログラミングでは、意味のないところに拘って時間を浪費する奴は多々居る。
お前もこれで、この程度なら読んだ瞬間分かるし、
（勘違いや見落としとかではなく)ガチで 'f_%' が 'foo' に一致するか分からないようならプログラミングを止めた方がいい。
普通なら、というか、自分で作りたい物があってSQLを使おうとしてる奴なら、こんなの読んだ瞬間に「はい分かった、次」でしかない。

初学者向けに環境を整備したいのであれば、インタラクティブ環境を整備する意味は大きいが、お前はそうではないのだろ。
それでも試したければ、所詮は正規表現の下位互換、どころかゴミ程度でしかないので、ブラウザでF12押してコンソールに
'foo'.search(new RegExp('f_%'.replace(/_/g,'.').replace(/%/g,'.*')))!==-1
とでも打てばいいだろうよ。でもこれもお前にとっては余計な回り道でしかないから、とっとと進むべきだと思うがな。

**デフォルトの名無しさん** · 2024/04/15(月) 12:03:59.29

>>250
やはり標準環境には無さそうな感じですか

LIKEはexprの一番簡単な例としてです
実際のところC系等の一般用途のプログラミング言語と比べてsqlのexpr文法って異常に複雑じゃありません？
https://sqlite.org/lang_expr.html

ASTも印字して欲しいくらいだけど、自分でパーサ書いてみるのも勉強になりそうですね

**デフォルトの名無しさん** · 2024/04/15(月) 12:45:09.95

普通の言語はstmtの構成要素としてexprが設けられるが、sqlでは逆にexprの中にstmtも入り得る異色の設計だから、exprサブセットのみの評価機は作れないね
まあstmtの評価は単にモックとして構文木を組んでみれば目的には適うし良い勉強になる

区切り文字をあまり使わないSQLは初学者には目に滑る構文だから特にそう

**デフォルトの名無しさん** · 2024/04/15(月) 12:57:20.78

>>251
評価の確認はおとなしくSQLiteに投げて、構文解析慣れてるようだし見本はこれ参考で十分だろう
https://sqlite.org/src/artifact/741a270b7f2f85bc

lemonって変わったパーサジェネレータ使ってるのけど、見た感じただのyacc変種なので出会ったトークン種別を単に印字させればよいだけ

**デフォルトの名無しさん** · 2024/04/15(月) 13:34:40.60

>>251
> やはり標準環境には無さそうな感じですか
実際要らんしね。SQLがCLIから打てるのだから普通はそれで十分。（普通は＝使う人にとっては)
PHPer連中はphpLiteAdminという、SQLがWebから打てる奴を使ってるようだが、動作レベルはCLIと同じでSQLだね。

> sqlのexpr文法って異常に複雑じゃありません？
さあ知らん.。というか俺は使う人であって、環境を構築する人ではないので、
ASTとか使ったこと無いし、yacc/lex/bisonあたりは触ったことが無い。
SQLも基本俺がコードに直接書く程度で、コード上でSQLを自動生成しようとはしたことは無いので分からん。
ただ、目がすべる＝SQLの区切りがよく分からん、という感じにはならなかった気がする。カッコ使えで終わるし。

方針として「あらゆる道草を食い、遠回りしてるうちに、全体的な力が養える」という考えの奴もいるが、
今やることがあるなら変なところに拘らず先に進んで実装して行ったほうがいいと思うぜ。
その先にもどのみちハードルはあるのだから、同様に学んではいけ、目標実現に直接近づける。

> ASTも印字して欲しいくらいだけど、自分でパーサ書いてみるのも勉強になりそうですね
ちなみにASTに関心があるのなら、Goの方がいい。あれは標準でAST木を吐ける。
あと、パーサも作るのは自由だが、SQLについては公開された仕様書がなかったはず。
SQL92なら特許は切れてるはずなのだけど。
それから、もうやってるだろうがexplainコマンドでクエリプランを出せる。ASTでは無いが、まあ似たようなものではあるだろう。

**デフォルトの名無しさん** · 2024/04/15(月) 14:00:04.64

>>252
sqliteの構文図見直したらしっかりselect-stmtってありますねえ…

>>253
まさに求めてたやつです、どうも
各処理系のパーサも見較べるとBison向けでルール/アクションの羅列のpsqlの奴が一番わかり易かった
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y

psql用だけど拡張や高度な機能を気にする段階に無いので、ここから必要そうなのを拾い始めました
sqliteのパーサは中でゴチャゴチャ処理してるけど、psqlのパーサはparser/*.cへアクション内で呼ぶ関数がキレイに分離されていて、記述的命名から意味論まで分かるお手本のようなデザインですね
座右の文法リファレンスとして印刷してそのまま使えそうな出来栄え

**デフォルトの名無しさん** · 2024/04/15(月) 14:07:24.63

>>254
忠告どうも
たまたまSQLという'言語'が面白そうで規格までしっかりある良さそうなもので意欲を得ました
もしこのSQL'言語'が肌に合わなかったならば、プログラミング言語同梱のリレーショナルデータベースAPIへロールバックするでしょう
私の主眼はスレタイ通りSQLにあります

**デフォルトの名無しさん** · 2024/04/15(月) 14:23:22.62

既にRDBバリバリ管理やってる人こそ学ぶべき
むしろ初学が厳しい見た目のSQLだと挫折率高そう
母語に流暢でも英語をサボる理由にはならない

API通ってる環境なら必然的に埋め込みSQLも使える