>>114
なるほど。さんくす。
ついでに、Rubyでユーザー登録や認証をした結果をMySQLの中に
データとして貯めるようなサーバーサイドのCGIのライブラリ
みたいなものは有る？
SQLなら俺に訊け [無断転載禁止]©2ch.net
115デフォルトの名無しさん
2021/01/19(火) 00:28:07.43ID:hiZmhE+d116デフォルトの名無しさん
2021/01/19(火) 00:45:19.71ID:sryyIgAN117デフォルトの名無しさん
2021/01/19(火) 00:47:54.79ID:hiZmhE+d Ruby on Rails の devise という「gem」が、パスワードを入力したり
メールを送って登録するようなよくある認証パターンをやってくれて、
MySQLも使ってるそうだけど、Ruby on Rails使ったことないし、
登録した MySQL のデータを上手く扱えるか不安。
メールを送って登録するようなよくある認証パターンをやってくれて、
MySQLも使ってるそうだけど、Ruby on Rails使ったことないし、
登録した MySQL のデータを上手く扱えるか不安。
118デフォルトの名無しさん
2021/02/08(月) 13:32:01.05ID:0mrKmB9v テーブル名にバインド変数使う事って出来ないの？
"CREATE TABLE IF NOT EXISTS ? (...);"
といった感じでテーブル名は後付けでバインドしたいんだけどsqlite3_prepare_v2が失敗する
"CREATE TABLE IF NOT EXISTS ? (...);"
といった感じでテーブル名は後付けでバインドしたいんだけどsqlite3_prepare_v2が失敗する
119デフォルトの名無しさん
2021/02/08(月) 14:34:00.76ID:0mrKmB9v 自己解決、
出来ないのが仕様だったか
出来ないのが仕様だったか
120デフォルトの名無しさん
2021/02/08(月) 16:39:30.22ID:KTkq0eI8 SQL ServerとOracleとDb2の3間を変換してくれるアプリとかありませんか？
121デフォルトの名無しさん
2021/02/09(火) 22:59:40.19ID:62IhLHy8 質問スレ過疎ってたからこっちか
専ブラBB2Cでワッチョイを正規表現でNGしたいんだけどうまくいかない
第2オクテット(仮にXXとして)だけ固定でこれじゃダメだろうか
.*XX-.*
専ブラBB2Cでワッチョイを正規表現でNGしたいんだけどうまくいかない
第2オクテット(仮にXXとして)だけ固定でこれじゃダメだろうか
.*XX-.*
122デフォルトの名無しさん
2021/02/10(水) 14:33:47.60ID:n+lQ6bEt sqlite3_blob_openで得た列ハンドルをsqlite3_reopen_blobで使いまわすとクエリ投げるより5倍近く高速だと判明したが
nullセルやrowが見つからないとハンドル失効しちゃってopenし直さないといけないんだな
open自体はそれなりに重いから失効が多いとパフォーマンス上の利点はほとんど無しか
nullセルやrowが見つからないとハンドル失効しちゃってopenし直さないといけないんだな
open自体はそれなりに重いから失効が多いとパフォーマンス上の利点はほとんど無しか
123デフォルトの名無しさん
2021/02/13(土) 18:50:09.35ID:k+FkZinH データベース板を忘れないでください
124デフォルトの名無しさん
2021/05/21(金) 10:11:21.48ID:bGYKMPx3 2万レコードのテーブルの全行をそれぞれupdateで値を変更したいんだが、これってforでSELECTを2万回繰り返したりしたらまずいもんなの？
レンタルサーバー使ってるんだが
レンタルサーバー使ってるんだが
125デフォルトの名無しさん
2021/05/21(金) 22:03:11.74ID:zqtp1sUR べつにまずくはないよ。オーバーヘッドが大きいだけ。
126デフォルトの名無しさん
2021/05/22(土) 21:16:11.45ID:GZBP0kYz >>125
ありがとうございます。めっちゃ助かりました
ありがとうございます。めっちゃ助かりました
127デフォルトの名無しさん
2021/07/10(土) 13:35:16.95ID:0S1tAkGn 一個前のidからカラム取ってくることはできますか？
128デフォルトの名無しさん
2021/07/10(土) 14:09:51.57ID:1/iYafxq 前とか後とかいう概念が、、、というのは置いといて
自分のidより小さいidの最大が該当のidだろ
あとはサブクエリなりwindow関数なりでとってこい
自分のidより小さいidの最大が該当のidだろ
あとはサブクエリなりwindow関数なりでとってこい
129デフォルトの名無しさん
2021/07/13(火) 23:04:11.03ID:oBbbWw6W 出来たわ！ありがとう
130デフォルトの名無しさん
2021/07/22(木) 23:59:45.26ID:zjMsrHKr SQLの述語というのがよくわかりません
131デフォルトの名無しさん
2021/10/15(金) 22:03:31.28ID:atwiHSUT レコードのデータが
AAA 1
AAA 2
BBB 3
BBB 4
BBB 5
CCC 6
CCC 7
AAA 8
AAA 9
BBB 10
BBB 11
ってなってるデータから
AAA 1
BBB 3
CCC 6
AAA 8
BBB 10
みたいなデータに変換したいのですがやる方法ってありますか
AAA 1
AAA 2
BBB 3
BBB 4
BBB 5
CCC 6
CCC 7
AAA 8
AAA 9
BBB 10
BBB 11
ってなってるデータから
AAA 1
BBB 3
CCC 6
AAA 8
BBB 10
みたいなデータに変換したいのですがやる方法ってありますか
132デフォルトの名無しさん
2021/10/15(金) 22:50:54.11ID:p2U7IjWk グループ化して、最小値だけを取り出せば？
133デフォルトの名無しさん
2021/10/16(土) 08:56:30.04ID:vbkw9O81 どういうルールで変換するのか書かないで丸投げされてもな。
というかそれを自分で考えないからわかんないんだろう。
というかそれを自分で考えないからわかんないんだろう。
134デフォルトの名無しさん
2021/10/16(土) 09:46:40.94ID:BnnoSLdm135デフォルトの名無しさん
2021/10/16(土) 11:27:24.16ID:wy7RR+Lb136デフォルトの名無しさん
2021/10/17(日) 10:18:00.58ID:O7pSNP76 すまん 俺が悪かった。
みんなありがとう
例えば、下記の時系列データがあったときに、nameごとにまとめたものを別のテーブルに入れたいんだよね。
nameがはまとめたときに、IDがもっとも若いものを格納したい。
SQLで一発取れたりするかな？
ロジックを考える必要ある？
ID(PK) name value
1 AAA 1
2 AAA 3
3 BBB 5
4 BBB 2
5 BBB 4
6 CCC 1
7 CCC 3
8 AAA 1
9 AAA 2
10 CCC 3
11 CCC 4
↓
ID(PK) name value
1 AAA 1
3 BBB 5
6 CCC 1
8 AAA 1
10 CCC 3
みんなありがとう
例えば、下記の時系列データがあったときに、nameごとにまとめたものを別のテーブルに入れたいんだよね。
nameがはまとめたときに、IDがもっとも若いものを格納したい。
SQLで一発取れたりするかな？
ロジックを考える必要ある？
ID(PK) name value
1 AAA 1
2 AAA 3
3 BBB 5
4 BBB 2
5 BBB 4
6 CCC 1
7 CCC 3
8 AAA 1
9 AAA 2
10 CCC 3
11 CCC 4
↓
ID(PK) name value
1 AAA 1
3 BBB 5
6 CCC 1
8 AAA 1
10 CCC 3
137デフォルトの名無しさん
2021/10/17(日) 10:20:12.93ID:O7pSNP76138デフォルトの名無しさん
2021/10/23(土) 10:22:47.90ID:D86LbS/L 時刻昇順に並んでるデータでstatusが1〜4を一塊として
縦横変換したテーブルが欲しいんですけどSQLだけじゃムリですかね。
欲しいテーブルにあるrep_idは元のテーブルにない（生成したい）です。
元のテーブル
time status
10/1 0:01 1
10/1 1:34 2
10/1 2:00 4
10/1 22:00 2
10/1 23:32 3
10/2 1:02 4
欲しいテーブル
rep_id| status_1 | status_2 | status_3 | status_4
-----+----------+-----------+----------+--------
1 |10/1 0:01 | 10/1 1:34 | null | 10/1 2:00
2 |null | 10/1 23:00 | 10/1 23:32 | 10/2 1:02
縦横変換したテーブルが欲しいんですけどSQLだけじゃムリですかね。
欲しいテーブルにあるrep_idは元のテーブルにない（生成したい）です。
元のテーブル
time status
10/1 0:01 1
10/1 1:34 2
10/1 2:00 4
10/1 22:00 2
10/1 23:32 3
10/2 1:02 4
欲しいテーブル
rep_id| status_1 | status_2 | status_3 | status_4
-----+----------+-----------+----------+--------
1 |10/1 0:01 | 10/1 1:34 | null | 10/1 2:00
2 |null | 10/1 23:00 | 10/1 23:32 | 10/2 1:02
139デフォルトの名無しさん
2021/10/23(土) 10:32:24.95ID:D86LbS/L 時刻昇順に並んでるデータでstatusが1〜4を一塊として
縦横変換したテーブルが欲しいんですけどSQLだけじゃムリですかね。
欲しいテーブルにあるrep_idは元のテーブルにない（生成したい）です。
元のテーブル
time status
10/1 0:01 1
10/1 1:34 2
10/1 2:00 4
10/1 22:00 2
10/1 23:32 3
10/2 1:02 4
10/2 4:05 4
10/3 18:30 2
10/3 20:34 2
欲しいテーブル
rep_id| status_1 | status_2 | status_3 | status_4
-----+----------+-----------+----------+--------
1 |10/1 0:01 | 10/1 1:34 | null | 10/1 2:00
2 |null | 10/1 23:00 | 10/1 23:32 | 10/2 1:02
3 |null | null | null | 10/2 4:05
4 |null | 10/3 18:30 | null | null
5 |null | 10/3 20:34 | null | null
縦横変換したテーブルが欲しいんですけどSQLだけじゃムリですかね。
欲しいテーブルにあるrep_idは元のテーブルにない（生成したい）です。
元のテーブル
time status
10/1 0:01 1
10/1 1:34 2
10/1 2:00 4
10/1 22:00 2
10/1 23:32 3
10/2 1:02 4
10/2 4:05 4
10/3 18:30 2
10/3 20:34 2
欲しいテーブル
rep_id| status_1 | status_2 | status_3 | status_4
-----+----------+-----------+----------+--------
1 |10/1 0:01 | 10/1 1:34 | null | 10/1 2:00
2 |null | 10/1 23:00 | 10/1 23:32 | 10/2 1:02
3 |null | null | null | 10/2 4:05
4 |null | 10/3 18:30 | null | null
5 |null | 10/3 20:34 | null | null
140デフォルトの名無しさん
2021/10/24(日) 00:25:59.14ID:4lHZz/Ub SQLだけでやってみた
WITH
ブレークチェック AS (
SELECT
CASE WHEN LAG(status,1,NULL) OVER (ORDER BY [time]) < status
THEN 0
ELSE 1
END AS st,
[time]
FROM 元のテーブル),
開始終了 AS (
SELECT
[time],
(SELECT MIN([time]) FROM ブレークチェック WHERE st = 1 AND [time] > t.[time]) AS end_time
FROM ブレークチェック t
WHERE st = 1),
t1 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 1),
t2 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 2),
t3 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 3),
t4 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 4)
SELECT ROW_NUMBER() OVER (ORDER BY 開始終了.[time]) AS rep_id,
t1.[time] AS status_1,
t2.[time] AS status_2,
t3.[time] AS status_3,
t4.[time] AS status_4
FROM 開始終了
LEFT JOIN t1 ON t1.[time] >= 開始終了.[time] AND (t1.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t2 ON t2.[time] >= 開始終了.[time] AND (t2.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t3 ON t3.[time] >= 開始終了.[time] AND (t3.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t4 ON t4.[time] >= 開始終了.[time] AND (t4.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
素直にループ回すほうがいいな
WITH
ブレークチェック AS (
SELECT
CASE WHEN LAG(status,1,NULL) OVER (ORDER BY [time]) < status
THEN 0
ELSE 1
END AS st,
[time]
FROM 元のテーブル),
開始終了 AS (
SELECT
[time],
(SELECT MIN([time]) FROM ブレークチェック WHERE st = 1 AND [time] > t.[time]) AS end_time
FROM ブレークチェック t
WHERE st = 1),
t1 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 1),
t2 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 2),
t3 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 3),
t4 AS (SELECT [time] FROM 元のテーブル WHERE [status] = 4)
SELECT ROW_NUMBER() OVER (ORDER BY 開始終了.[time]) AS rep_id,
t1.[time] AS status_1,
t2.[time] AS status_2,
t3.[time] AS status_3,
t4.[time] AS status_4
FROM 開始終了
LEFT JOIN t1 ON t1.[time] >= 開始終了.[time] AND (t1.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t2 ON t2.[time] >= 開始終了.[time] AND (t2.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t3 ON t3.[time] >= 開始終了.[time] AND (t3.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
LEFT JOIN t4 ON t4.[time] >= 開始終了.[time] AND (t4.[time] < 開始終了.[end_time] OR 開始終了.end_time IS NULL)
素直にループ回すほうがいいな
141デフォルトの名無しさん
2021/10/24(日) 07:39:02.37ID:djVQHxKk142デフォルトの名無しさん
2021/11/06(土) 13:34:50.16ID:ABCltTaS 検索やら削除、CRUDをしたあとに得られるデータの命名に
rowsとかitems、個々はrowやitem
と考えています。
さらに個々rowにはdeleteやupdateのメソッドが使えるよう処理しています
つまり純粋なデータというよりインスタンス化されています
ここで疑問が。
rowという命名がしっくりこない気がします
row.column名やらrow.delete()とかで使う分にはrowで良いと思いますが
rowオブジェクトのクラス名をRowにするのはぴんとこないのです
何かいい命名案はないでしょうか
もうItemでいいかなとも思ってます
rowsとかitems、個々はrowやitem
と考えています。
さらに個々rowにはdeleteやupdateのメソッドが使えるよう処理しています
つまり純粋なデータというよりインスタンス化されています
ここで疑問が。
rowという命名がしっくりこない気がします
row.column名やらrow.delete()とかで使う分にはrowで良いと思いますが
rowオブジェクトのクラス名をRowにするのはぴんとこないのです
何かいい命名案はないでしょうか
もうItemでいいかなとも思ってます
143デフォルトの名無しさん
2021/11/06(土) 19:03:36.97ID:zfMx2fqR Row/Columnは行/列だから表(Table)に対しての名前はフィットしていると思うがな。
気に入らなければRecord/Flieldではどうかな？
気に入らなければRecord/Flieldではどうかな？
144デフォルトの名無しさん
2021/11/07(日) 12:35:47.69ID:X+EdCY7G ありがとうございます >>143
一括置換しても問題なくいつでも変えられそうなのでとりあえずはRowにしときます
一括置換しても問題なくいつでも変えられそうなのでとりあえずはRowにしときます
145デフォルトの名無しさん
2021/11/14(日) 11:47:27.97ID:wWg1lz8i 日本全国民テーブルから
年収960万円以下の世帯で、
かつ
18才未満の子供の数。
を抽出するSQLを書いて下さい
年収960万円以下の世帯で、
かつ
18才未満の子供の数。
を抽出するSQLを書いて下さい
146デフォルトの名無しさん
2021/11/14(日) 12:12:19.12ID:DPFsPWqC147デフォルトの名無しさん
2021/11/14(日) 13:47:45.91ID:E00roTgy 電通もしくはぱーそるの人か
148デフォルトの名無しさん
2021/11/14(日) 15:11:57.53ID:FPcp9uu4 んなわけねーw
5ちゃん見てたら笑うしか無いw
5ちゃん見てたら笑うしか無いw
149デフォルトの名無しさん
2021/11/14(日) 15:16:56.72ID:mFG9NQD5 >>142
Ruby on Rails のO/R マッパーでは、
命名規約で決まっているから、row みたいな抽象的な名前にならない
テーブル名が複数形のmy_books(snake case)なら、
各行は、単数型のmy_book を使えばよい
クラス名は、MyBooks(Pascal, upper camel)
ファイル名は、my_book.rb
Ruby on Rails のO/R マッパーでは、
命名規約で決まっているから、row みたいな抽象的な名前にならない
テーブル名が複数形のmy_books(snake case)なら、
各行は、単数型のmy_book を使えばよい
クラス名は、MyBooks(Pascal, upper camel)
ファイル名は、my_book.rb
150デフォルトの名無しさん
2021/11/14(日) 16:50:43.91ID:tkHjD9h1 便通はfirewallで5ch禁止してるからな
自宅から業務外で5chに質問描いてたらクビ
自宅から業務外で5chに質問描いてたらクビ
151デフォルトの名無しさん
2021/11/25(木) 19:15:00.80ID:zZUF+qfu selectはそこそこ速いのに（30秒くらいで処理終わる） updateにすると遅くなる（10分以上）要因って何が怪しいかわかる？
抽出条件は全く一緒
抽出条件は全く一緒
152デフォルトの名無しさん
2021/11/25(木) 19:15:06.69ID:zZUF+qfu selectはそこそこ速いのに（30秒くらいで処理終わる） updateにすると遅くなる（10分以上）要因って何が怪しいかわかる？
抽出条件は全く一緒
抽出条件は全く一緒
153デフォルトの名無しさん
2021/11/25(木) 20:31:30.88ID:662tr9PH154デフォルトの名無しさん
2021/11/25(木) 21:42:40.77ID:rnpiht7q selectとupdateで経過時間を比較してもあんまり意味ないよ
抽出条件は同じでもupdateは抽出後に1件1件更新処理が必要なんだから
件数が多ければそのくらいの差になっても何も不思議じゃない
抽出条件は同じでもupdateは抽出後に1件1件更新処理が必要なんだから
件数が多ければそのくらいの差になっても何も不思議じゃない
155デフォルトの名無しさん
2021/12/24(金) 16:39:20.24ID:unjC7EWw 複数のカラムのどれかに該当文字を含む行を知りたいが、
どのカラムだったかで区別したい時に、一発でやる方法ってある？
具体的には以下(２発)を一発にしたい。
SELECT 0,target FROM sometable WHERE col0 MATCH 'str' UNION SELECT 1,target FROM sometable WHERE col1 MATCH 'str' AND col0 NOT MATCH 'str';
例えば、「どのORに当たったか」を教えてくれるスカラー関数 hitplace() があったとすると、
SELECT hitplace(),target FROM sometable WHERE col0 MATCH 'str' OR col1 MATCH 'str';
に出来るのだけど。
環境はPHP+SQLite。
出力は配列の配列、 [[col0に当たった行],[col1に当たった行]] の形式で、重複はなし。
この形式にサクッと変換出来るのなら、読み出した形式は上記とは違っても可。
どのカラムだったかで区別したい時に、一発でやる方法ってある？
具体的には以下(２発)を一発にしたい。
SELECT 0,target FROM sometable WHERE col0 MATCH 'str' UNION SELECT 1,target FROM sometable WHERE col1 MATCH 'str' AND col0 NOT MATCH 'str';
例えば、「どのORに当たったか」を教えてくれるスカラー関数 hitplace() があったとすると、
SELECT hitplace(),target FROM sometable WHERE col0 MATCH 'str' OR col1 MATCH 'str';
に出来るのだけど。
環境はPHP+SQLite。
出力は配列の配列、 [[col0に当たった行],[col1に当たった行]] の形式で、重複はなし。
この形式にサクッと変換出来るのなら、読み出した形式は上記とは違っても可。
156デフォルトの名無しさん
2021/12/24(金) 17:59:49.49ID:cMhJNtck CASE式使えばできるよ
アプリかDBの設計を見直したほうがいい可能性大
アプリかDBの設計を見直したほうがいい可能性大
157デフォルトの名無しさん
2021/12/24(金) 19:31:42.64ID:unjC7EWw お早い回答ありがとう。
もっと色々試すが取り急ぎ。
新案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 も全く同じ。
もっと色々試すが取り急ぎ。
新案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 も全く同じ。
158デフォルトの名無しさん
2021/12/24(金) 19:32:06.67ID:unjC7EWw 元：
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やアプリ構造の改善案は今のところ思いつかない。(変更は可能)
カラムはそれぞれ別の管理なので、先に合わせる事は出来ない。
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やアプリ構造の改善案は今のところ思いつかない。(変更は可能)
カラムはそれぞれ別の管理なので、先に合わせる事は出来ない。
159デフォルトの名無しさん
2021/12/24(金) 21:34:31.41ID:unjC7EWw 新案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の中身が埋まるまでにはだいぶかかるとは思う。
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の中身が埋まるまでにはだいぶかかるとは思う。
160デフォルトの名無しさん
2021/12/24(金) 21:37:57.02ID:cMhJNtck >>157
その案はどちらもテーブルスキャンになってインデックス使わない
SELECT句のCASE式とは別にWHERE句に本来の条件を書く
DB構造の話はカラムとして持つべきデータじゃなくて
子テーブルの行として持つべきデータかと思ったんだけど
全文検索でいずれかのカラムに検索キーワードが含まれてる行を
どのカラムかという情報も含めて抽出する用途なんであれば
そのままでいいんじゃないかと思う
その案はどちらもテーブルスキャンになってインデックス使わない
SELECT句のCASE式とは別にWHERE句に本来の条件を書く
DB構造の話はカラムとして持つべきデータじゃなくて
子テーブルの行として持つべきデータかと思ったんだけど
全文検索でいずれかのカラムに検索キーワードが含まれてる行を
どのカラムかという情報も含めて抽出する用途なんであれば
そのままでいいんじゃないかと思う
161デフォルトの名無しさん
2021/12/24(金) 22:28:50.21ID:unjC7EWw >>160
> その案はどちらもテーブルスキャンになってインデックス使わない
そうだが、今回はこれで仕様的にも問題ない。
俺が勘違いしてたのもあって言葉が混乱しているが、
SQLiteのFTSは全文検索仕様で、通常のインデックスは作成出来ない。
FTSで「インデックス」と言われてるのは全文検索用のキーワードインデックスで、
つまりMATCHがLIKEに比べて糞速いだけで、常に全row検索する仕様のようだ。
https://sqlite.org/fts3.html
（俺がFTSの「インデックス」をここでもそのままインデックスと表記したのが不味かった。
FTS用のテーブルでは通常のインデックスでの単rowからの検索は出来ない。
《rowidだけは使えるらしいが、使っても explain query plan では scan と表示された》)
> 子テーブルの行として持つべきデータかと思ったんだけど
あーなるほど、勘がいいね。
実は元々そういう構造になっていたのだが、
下部構造のサマリを作ってしまった方が楽だからそうしようとしていて、
col0は上部から与える名前、col1は下部のそれぞれの中身の寄せ集めになってる。
だからcol0を下部構造の各行のcol1相当部分に対して混ぜ込めば、下部構造で一発クエリ出来る。
そして元々そうしていたのだが、他の都合上、管理が面倒なので変更しようとしているところ。
しかしよく分かったね。まあ妙な事をしてるからか？
まあとにかくありがとう。
今回は下部構造のサマリなので、常に全文検索で問題ない。
言葉が混乱しててごめん。
> その案はどちらもテーブルスキャンになってインデックス使わない
そうだが、今回はこれで仕様的にも問題ない。
俺が勘違いしてたのもあって言葉が混乱しているが、
SQLiteのFTSは全文検索仕様で、通常のインデックスは作成出来ない。
FTSで「インデックス」と言われてるのは全文検索用のキーワードインデックスで、
つまりMATCHがLIKEに比べて糞速いだけで、常に全row検索する仕様のようだ。
https://sqlite.org/fts3.html
（俺がFTSの「インデックス」をここでもそのままインデックスと表記したのが不味かった。
FTS用のテーブルでは通常のインデックスでの単rowからの検索は出来ない。
《rowidだけは使えるらしいが、使っても explain query plan では scan と表示された》)
> 子テーブルの行として持つべきデータかと思ったんだけど
あーなるほど、勘がいいね。
実は元々そういう構造になっていたのだが、
下部構造のサマリを作ってしまった方が楽だからそうしようとしていて、
col0は上部から与える名前、col1は下部のそれぞれの中身の寄せ集めになってる。
だからcol0を下部構造の各行のcol1相当部分に対して混ぜ込めば、下部構造で一発クエリ出来る。
そして元々そうしていたのだが、他の都合上、管理が面倒なので変更しようとしているところ。
しかしよく分かったね。まあ妙な事をしてるからか？
まあとにかくありがとう。
今回は下部構造のサマリなので、常に全文検索で問題ない。
言葉が混乱しててごめん。
162デフォルトの名無しさん
2021/12/25(土) 19:58:56.64ID:GPUeNtJx 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で行く予定。
ただし動的エラーで、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で行く予定。
163デフォルトの名無しさん
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
SQLModelにてRelationshipsがうまく機能しなかったが
結論としてSQLAlchemyのバージョンを変更したらうまくいった
https://github.com/tiangolo/sqlmodel/issues/327#issuecomment-1116983382
他のバージョンは試してないが
pip install SQLAlchemy==1.4.17
でいけた
#python #SQLModel
164デフォルトの名無しさん
2022/05/28(土) 08:36:34.97ID:2HB62XT0 カーソルって何のために使うの？
165デフォルトの名無しさん
2022/05/28(土) 11:06:08.08ID:81XaDMLN iteration
166デフォルトの名無しさん
2022/05/28(土) 12:02:17.61ID:WzAPHv6Z167デフォルトの名無しさん
2022/05/28(土) 16:19:02.25ID:63kkWN4T SQLでDECLARE CURSORと書くサーバーサイドのカーソルと
DBドライバーのAPIが提供するクライアントサイドのカーソルは別のもの
前者はSQLで1行単位の処理をしたい場合に使うものだけどよほど特殊な事情がない限りは使わない
後者はクライアントがクエリの結果セットを塊単位でフェッチするのに使うもので呼び名が違うこともあるが一般的に使われてる
どちらも結果セット内の次の読み込み位置を指し示す抽象オブジェクトとしての役割は同じ
DBドライバーのAPIが提供するクライアントサイドのカーソルは別のもの
前者はSQLで1行単位の処理をしたい場合に使うものだけどよほど特殊な事情がない限りは使わない
後者はクライアントがクエリの結果セットを塊単位でフェッチするのに使うもので呼び名が違うこともあるが一般的に使われてる
どちらも結果セット内の次の読み込み位置を指し示す抽象オブジェクトとしての役割は同じ
168デフォルトの名無しさん
2022/06/07(火) 20:12:44.49ID:SiB5OW5s 車テーブルがあって
車両番号 走行日 走行距離(出発) 走行距離(到着) 運転手
というカラムがあります。
各車両の現在の走行距離と、今運転手が乗っていれば運転手名が欲しいです。
乗っているという判断は
走行距離(出発)が入ってるけど到着は入ってない、という事になってます。
これってMAX関数で現在の走行距離とるクエリと、運転手データとるクエリとでJOINするしかないですよね？
車両番号 走行日 走行距離(出発) 走行距離(到着) 運転手
というカラムがあります。
各車両の現在の走行距離と、今運転手が乗っていれば運転手名が欲しいです。
乗っているという判断は
走行距離(出発)が入ってるけど到着は入ってない、という事になってます。
これってMAX関数で現在の走行距離とるクエリと、運転手データとるクエリとでJOINするしかないですよね？
169デフォルトの名無しさん
2022/06/07(火) 22:18:49.63ID:vS63Cws5170デフォルトの名無しさん
2022/06/08(水) 02:38:50.06ID:m+BIRTG0171デフォルトの名無しさん
2022/06/08(水) 04:53:57.00ID:8AxfQ9fg GROUP BYの集計項目以外のカラムの値(運転手等)をサブクエリ使わずに一発でできるかどうかという質問かと思ったが
運転手を表示する場合としない場合の分岐方法の話ならCASE式だね
運転手を表示する場合としない場合の分岐方法の話ならCASE式だね
175デフォルトの名無しさん
2022/06/14(火) 14:33:53.86ID:eTPeyH+k SQL Serverで質問です。
テーブル1
テーブル2
テーブル3
テーブル4
…
とテーブルはどんどん増えます。
各テーブルにはIDという数値型のフィールドがあるのですが、
テーブル名とIDの最大値の一覧表にしたいです。
INFORMATION_SCHEMAを使ってテーブル名の一覧までは出せたのですが、
それらの各IDの最大値を産出するのはどう書けばいいのでしょうか？
テーブル1
テーブル2
テーブル3
テーブル4
…
とテーブルはどんどん増えます。
各テーブルにはIDという数値型のフィールドがあるのですが、
テーブル名とIDの最大値の一覧表にしたいです。
INFORMATION_SCHEMAを使ってテーブル名の一覧までは出せたのですが、
それらの各IDの最大値を産出するのはどう書けばいいのでしょうか？
176デフォルトの名無しさん
2022/06/14(火) 15:30:50.28ID:EXjYCut5 >>175
identity columnなら
SELECT IDENT_CURRENT (‘table_name’)かsys.identity_columnsのlast_value
違うなら
SELECT MAX(ID) FROM table_name
identity columnなら
SELECT IDENT_CURRENT (‘table_name’)かsys.identity_columnsのlast_value
違うなら
SELECT MAX(ID) FROM table_name
177デフォルトの名無しさん
2022/06/14(火) 16:44:05.01ID:eTPeyH+k >>176 ありがとうございます。
しかしながら
テーブル名 IDの最大値
テーブル1 6
テーブル2 1014
テーブル3 1990
テーブル4 74
テーブル5 1861
テーブル6 136
という感じに表示されてほしいです
しかしながら
テーブル名 IDの最大値
テーブル1 6
テーブル2 1014
テーブル3 1990
テーブル4 74
テーブル5 1861
テーブル6 136
という感じに表示されてほしいです
178デフォルトの名無しさん
2022/06/15(水) 20:45:45.59ID:W3daPLoz 一つのテーブルに対して、複数のクエリ（参照、更新）が同時に投げられても、テーブルロックされない限り並行して動くものなの？
179デフォルトの名無しさん
2022/06/17(金) 01:53:08.02ID:qX3KJPna180デフォルトの名無しさん
2022/06/22(水) 21:18:18.43ID:JRkIVgOU >>177
それなら統計情報を検索すればいい話
それなら統計情報を検索すればいい話
181デフォルトの名無しさん
2022/06/29(水) 17:50:51.99ID:EbiKHqB9 全く同じクエリの処理してるのに、時間帯によって波があるのって何が原因かな？
夜中は１０秒、朝９時くらいは1時間とかザラにある
しかも、毎日波がある
こんなに気まぐれなの?
夜中は１０秒、朝９時くらいは1時間とかザラにある
しかも、毎日波がある
こんなに気まぐれなの?
182デフォルトの名無しさん
2022/06/29(水) 18:45:17.79ID:GkfgkD+E183デフォルトの名無しさん
2022/06/29(水) 18:51:34.33ID:IbvhvF4u >>182
情報が欲しいなら、お願いしてみれば？
情報が欲しいなら、お願いしてみれば？
184デフォルトの名無しさん
2022/06/29(水) 18:59:48.80ID:fypNMUMK 情報はタダじゃねえんだよ
185デフォルトの名無しさん
2022/06/29(水) 21:10:29.16ID:RWZIP4V9 10秒と1時間越えで何が原因かあたりもつけられないってかなりヤバない？
186デフォルトの名無しさん
2022/06/29(水) 21:18:34.19ID:zCehF1Jn マシンのメモリなどの、何かのリソースが少ないのかも
例えばメモリが少ないと、1クリックしてから処理されるまで、1分掛かる。
遅すぎて何もできない
例えばメモリが少ないと、1クリックしてから処理されるまで、1分掛かる。
遅すぎて何もできない
187デフォルトの名無しさん
2022/06/30(木) 16:46:00.43ID:4XQ6AH+7 バラバラな日付が入っているテーブルから、
特定日以前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
を取りたいです
特定日以前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
を取りたいです
188デフォルトの名無しさん
2022/06/30(木) 17:49:50.05ID:1+oYjPxt その日付より小さくて、その日付ー３日より大きいっていうwhere条件書くだけだと思うが
日付の扱いはＤＢＭＳによって差が大きいからこれ以上はちゃんと環境書け
日付の扱いはＤＢＭＳによって差が大きいからこれ以上はちゃんと環境書け
189デフォルトの名無しさん
2022/06/30(木) 17:56:20.31ID:eK6suSY8190デフォルトの名無しさん
2022/06/30(木) 18:54:13.55ID:6sehYChL >>189
ソートしろとは言ってないぞ
ソートしろとは言ってないぞ
191デフォルトの名無しさん
2022/06/30(木) 19:51:26.35ID:4XQ6AH+7192デフォルトの名無しさん
2022/06/30(木) 20:18:37.20ID:1+oYjPxt193デフォルトの名無しさん
2022/06/30(木) 20:29:12.21ID:6sehYChL >>192
ソートする必要がどこにあるのか？
ソートする必要がどこにあるのか？
194デフォルトの名無しさん
2022/06/30(木) 20:31:30.23ID:6sehYChL 3日が3レコードという意味なのかどうかからわからない。
195デフォルトの名無しさん
2022/06/30(木) 21:19:29.49ID:y+cu0wpZ >>192
自分より大きくて指定日付以下であるレコードが3件未満となるものを選ぶ。
自分より大きくて指定日付以下であるレコードが3件未満となるものを選ぶ。
196デフォルトの名無しさん
2022/06/30(木) 22:57:01.80ID:1+oYjPxt >>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とかでも動くな
なるほど。件数がゼロ件になるやつの考慮がいるけど、いけるのはいけそうだな
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とかでも動くな
197デフォルトの名無しさん
2022/06/30(木) 23:12:15.50ID:y+cu0wpZ198デフォルトの名無しさん
2022/07/01(金) 00:36:44.48ID:oYJ8x66X >>197
無駄なソートはRDBMSによっては致命的な性能問題を引き起こす。
無駄なソートはRDBMSによっては致命的な性能問題を引き起こす。
199デフォルトの名無しさん
2022/07/01(金) 03:40:55.11ID:42pyAc9U >>198
「無駄な」ソートはな
order by 書けば絶対ソートするとでも思ってるんだろうか
つかおまえソートしない方法提示できてないだろ
テーブルスキャン何回もやるぐらいならソート１回のほうがましなことも多いぞ
まあなんにせよインデックス構成とオプティマイザ次第だけどな
「無駄な」ソートはな
order by 書けば絶対ソートするとでも思ってるんだろうか
つかおまえソートしない方法提示できてないだろ
テーブルスキャン何回もやるぐらいならソート１回のほうがましなことも多いぞ
まあなんにせよインデックス構成とオプティマイザ次第だけどな
200デフォルトの名無しさん
2022/07/01(金) 09:55:27.56ID:g3tdjjPX TOP/LIMIT/FETCH FIRST + ORDER BY使ったtop-Nクエリが
相関サブクエリ使ったtop-Nクエリより遅くなるようなメジャーなDBMSがあるの？
相関サブクエリ使ったtop-Nクエリより遅くなるようなメジャーなDBMSがあるの？
201デフォルトの名無しさん
2022/07/02(土) 00:59:29.77ID:1zpQKBp2 構文の話をし始めるやつはヤバい
202デフォルトの名無しさん
2022/07/02(土) 09:03:05.11ID:Px5GXeoa 構文の話は誰もしてない・・・よね？
203デフォルトの名無しさん
2022/07/02(土) 19:31:42.58ID:1zpQKBp2 内部の処理の説明をSQLの構文で説明するのは、知識がなさすぎると思うぞ。
少なくとも業務システムでは嫌われる。
少なくとも業務システムでは嫌われる。
204デフォルトの名無しさん
2022/07/02(土) 20:23:17.28ID:MgQFVCuv 構文の話してるヤバい奴ってどれ？
というか、こういうどこに向かって話してるのかわからないようなのもなんかヤバい。
というか、こういうどこに向かって話してるのかわからないようなのもなんかヤバい。
205デフォルトの名無しさん
2022/07/02(土) 21:48:05.38ID:/9h4i5Tx これDB板によく湧くヤバいやつだわ
そっ閉じ推奨
そっ閉じ推奨
206デフォルトの名無しさん
2022/07/03(日) 12:56:59.34ID:UY7Pdi/e つかDB板の連中って何でそれが重い処理なのかまるで理解してないよね
しかも呼び出し側含めた全体最適化なんてする気もないようだし、
あいつらはSQLを手打ちでもしてるのだろうか？
しかも呼び出し側含めた全体最適化なんてする気もないようだし、
あいつらはSQLを手打ちでもしてるのだろうか？
207デフォルトの名無しさん
2022/07/03(日) 21:52:19.27ID:3LHO0qyv まるですでに重いと決まっているかのような物言い。これはヤヴァイ。
208デフォルトの名無しさん
2022/07/03(日) 22:24:10.66ID:UY7Pdi/e インデックスを張ってる状態での189は間違いなく軽い
DB屋はDBで済ませる傾向があるとは聞くし、
クエリプランナで最高に最適化されてリングバッファ的に動くのなら196も確かに軽いが、
そうならない場合は糞重い
俺はそこまでDBのことは知らないので、
189が第一選択肢で、速度の問題があればインデックスを張る
これで問題がある場合は、自前でカーソルをとってリングバッファを実装する
DB屋なら196がそれぞれのDBで軽いか重いか把握した状態で使うのだとは思う
ただそれは俺らプログラマとはだいぶ視点が違うと感じた
DB屋はDBで済ませる傾向があるとは聞くし、
クエリプランナで最高に最適化されてリングバッファ的に動くのなら196も確かに軽いが、
そうならない場合は糞重い
俺はそこまでDBのことは知らないので、
189が第一選択肢で、速度の問題があればインデックスを張る
これで問題がある場合は、自前でカーソルをとってリングバッファを実装する
DB屋なら196がそれぞれのDBで軽いか重いか把握した状態で使うのだとは思う
ただそれは俺らプログラマとはだいぶ視点が違うと感じた
209デフォルトの名無しさん
2022/07/03(日) 23:34:25.47ID:fr0a/itN ソートの話は相関サブクエリを使えという話じゃなく
指定日以前の任意の3レコードなのか(ソート無し)
指定日以前の直近の3レコードなのか(ソート有り)
という違いを指摘したかったんでしょ
指定日以前の任意の3レコードなのか(ソート無し)
指定日以前の直近の3レコードなのか(ソート有り)
という違いを指摘したかったんでしょ
210デフォルトの名無しさん
2022/07/04(月) 01:22:49.55ID:7pHsiooe それもあるとは思ったが、187だとほぼid通りの順なのだろうし、
191で文句も言ってないので、おそらくログ的な物のラスト3行を取りたいのだろうよ
なら俺は208で言ったとおりにする
(なお俺は189ではない)
それを(実際どうなるのかは知らんが)糞遅くなりそうなSQLを出すのもいかがなものかと
質問者が悪いと言えばそうだが、
質問者のレベル推定も含めての回答にしないと、ここでは成り立たない
「ソートして良い」と勝手に決めるのが問題なら、
「ソートしてはいけない」と勝手に決めるのもまた問題でしかない
なら聞けばいいのに、それもしない
（なお、しても意味は通じず、余計に面倒になるのは見えているので、
今回のようにいきなり189で問題ないとも思うが）
なんというか、この辺の空回り具合は、文化の違いを俺は感じたよ
ただまあ俺らが特殊なのかもしれないけどな
この板では基本的にエスパー出来ないと回答は無理だし
191で文句も言ってないので、おそらくログ的な物のラスト3行を取りたいのだろうよ
なら俺は208で言ったとおりにする
(なお俺は189ではない)
それを(実際どうなるのかは知らんが)糞遅くなりそうなSQLを出すのもいかがなものかと
質問者が悪いと言えばそうだが、
質問者のレベル推定も含めての回答にしないと、ここでは成り立たない
「ソートして良い」と勝手に決めるのが問題なら、
「ソートしてはいけない」と勝手に決めるのもまた問題でしかない
なら聞けばいいのに、それもしない
（なお、しても意味は通じず、余計に面倒になるのは見えているので、
今回のようにいきなり189で問題ないとも思うが）
なんというか、この辺の空回り具合は、文化の違いを俺は感じたよ
ただまあ俺らが特殊なのかもしれないけどな
この板では基本的にエスパー出来ないと回答は無理だし
211デフォルトの名無しさん
2022/07/12(火) 22:08:19.53ID:PV1bWVal SQLで４桁文字列'hhmm'とDatetime型を結合する方法って分かる？
例：
’1234’ char型
’2022/07/12 00:00:000’ datetime型 があったときに、
↓
2022/07/12 12:34:000 datetime型 みたいに結合したいんだけど。。
例：
’1234’ char型
’2022/07/12 00:00:000’ datetime型 があったときに、
↓
2022/07/12 12:34:000 datetime型 みたいに結合したいんだけど。。
212デフォルトの名無しさん
2022/07/12(火) 23:46:03.19ID:xDQ7ywi9 とりあえず'1234'を12と34の数字にして、元の日付に12時間と34分を足せばいいんじゃねふ
日付まわりはDBMSによって違うから
日付時刻をサポートしてるDBMSなら指定の時間、分を足す関数かなんかがあるだろうからそれ調べて使え
日付まわりはDBMSによって違うから
日付時刻をサポートしてるDBMSなら指定の時間、分を足す関数かなんかがあるだろうからそれ調べて使え
213デフォルトの名無しさん
2022/07/13(水) 13:38:16.35ID:HJBy50ka https://wandbox.org/permlink/TWt0aMILwOZlhQwu
front-page.phpのPHPとarchive.phpのSQLをつなげたいのですが、コンテンツが何も表示されません。
どうすればよいのでしょうか…
※参考サイト
https://cosybench.com/customize-wp-archives-look/
front-page.phpのPHPとarchive.phpのSQLをつなげたいのですが、コンテンツが何も表示されません。
どうすればよいのでしょうか…
※参考サイト
https://cosybench.com/customize-wp-archives-look/
214デフォルトの名無しさん
2022/07/13(水) 16:51:17.49ID:mLEjbAz1 変数設定が抜けておりました
215デフォルトの名無しさん
2022/07/13(水) 20:55:05.36ID:d4+uION0 >>211
関数
関数
216デフォルトの名無しさん
2022/07/15(金) 12:26:52.71ID:GqllWW3Z217デフォルトの名無しさん
2022/07/25(月) 21:13:25.51ID:FznTbXtw 複数のselect count(※)を1つのファイルに出力する方法教えてください。。
218デフォルトの名無しさん
2022/07/25(月) 22:10:59.17ID:bIl9FMxT SQLで急にファイル出力とか言われても何のこっちゃ分からんわ
シェルスクリプトで普通にappendでもしろや
シェルスクリプトで普通にappendでもしろや
219デフォルトの名無しさん
2022/07/28(木) 20:47:41.93ID:oYIQQ6EM ネタに反応すんな
220デフォルトの名無しさん
2022/11/10(木) 10:38:00.26ID:5Ugvs3e+ explain analyzeを付けると１秒、付けないと30秒かかるクエリがあるのですが一般的には何が原因なのでしょうか
221デフォルトの名無しさん
2022/11/10(木) 12:15:12.96ID:8Ccihq77222デフォルトの名無しさん
2022/11/17(木) 10:16:58.88ID:gy0rtS5S SQL Server 2022 正式リリース(米国11/16日)
MSDNダウンロードサイトでDeveloper EditionのISOリリースを確認
MSDNダウンロードサイトでDeveloper EditionのISOリリースを確認
223デフォルトの名無しさん
2023/02/12(日) 18:13:43.26ID:fJXtAG7P phpMyAdmin使ってます。
型が合わないデータの入力があったとき、
拒否するか、無理やりデフォルトの値を登録するか。
それを設定するコンパネとかありますか？
型が合わないデータの入力があったとき、
拒否するか、無理やりデフォルトの値を登録するか。
それを設定するコンパネとかありますか？
224デフォルトの名無しさん
2023/08/25(金) 10:09:06.20ID:AK+z9ndV ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数って言われてるけど普通にRETURNできるやん
歴史的な背景でもあるんか
それとも解説者か俺があほなんか
歴史的な背景でもあるんか
それとも解説者か俺があほなんか
225デフォルトの名無しさん
2023/08/25(金) 14:00:50.18ID:5+gJach+ 論理演算が弱すぎる
226デフォルトの名無しさん
2023/08/25(金) 18:18:42.69ID:DhQDvuMa >>224
一部のDBMSの古いバージョンではOUT/INOUT引数を使わないと値を返せなかったんだよ
一部のDBMSの古いバージョンではOUT/INOUT引数を使わないと値を返せなかったんだよ
227デフォルトの名無しさん
2023/08/30(水) 22:18:57.94ID:+4EyrP3p >>4
全列ｎｕｌｌでも？
全列ｎｕｌｌでも？
228デフォルトの名無しさん
2023/08/31(木) 14:07:47.09ID:nrSGXsFq >>224
それはファンクション(関数)とストアドプロシージャの違いがあまりないDBMSの場合
それはファンクション(関数)とストアドプロシージャの違いがあまりないDBMSの場合
229デフォルトの名無しさん
2023/08/31(木) 14:16:19.77ID:nrSGXsFq ファンクションは戻り値があるプロシージャという意味
230デフォルトの名無しさん
2023/08/31(木) 14:31:41.51ID:6hJq0gPI 違う
それは特定ベンダーの勝手な解釈
それは特定ベンダーの勝手な解釈
231デフォルトの名無しさん
2023/08/31(木) 15:20:59.08ID:nrSGXsFq 元はユーザー定義関数
232デフォルトの名無しさん
2023/08/31(木) 15:26:10.21ID:nrSGXsFq VBもAda言語もそうだけど、ファンクションプロシージャとサブプロシージャをわけているのは、プログラミング言語ではめずらしくない。
C言語、C言語に影響を受けた言語だと、わざわざ戻り値なしをvoidと書いて明確にする。
ファンクションは戻り値を利用するもの。戻り値を呼び出し側が無視できる仕様かどうかの問題。
C言語、C言語に影響を受けた言語だと、わざわざ戻り値なしをvoidと書いて明確にする。
ファンクションは戻り値を利用するもの。戻り値を呼び出し側が無視できる仕様かどうかの問題。
233デフォルトの名無しさん
2023/08/31(木) 16:29:25.54ID:JttiXEFt SQL標準的にはプロシージャに戻り値があるかどうかはimplementation defined
戻り値があったほうが便利なので多くのDBMSベンダーはscalar valueとresult setのどちらも返せるようにしてる
一方(ストアド)ファンクションはSQL標準で戻り値が必須でscalar valueのみと定められている
プログラミング言語でファンクションとプロシージャを区別してたのは太古の昔の話
今ではもうそんな区別に価値はなくなってる
SQL標準で区別されてるのは利用方法や利用する場所が基本的に違うため
戻り値があったほうが便利なので多くのDBMSベンダーはscalar valueとresult setのどちらも返せるようにしてる
一方(ストアド)ファンクションはSQL標準で戻り値が必須でscalar valueのみと定められている
プログラミング言語でファンクションとプロシージャを区別してたのは太古の昔の話
今ではもうそんな区別に価値はなくなってる
SQL標準で区別されてるのは利用方法や利用する場所が基本的に違うため
234デフォルトの名無しさん
2023/08/31(木) 16:31:16.87ID:nbJL0Jax MySQL系はファンクションだと、COMMITなどのトランザクション制御ができないので、あまり考えずにファンクションで統一などしてはならない。
235デフォルトの名無しさん
2023/08/31(木) 16:41:03.73ID:nbJL0Jax >>233
前半と後半で違う説明をしているね。
ファンクションは「関数」だ。
OUTパラメータを参照するのは「手続き」という処理だ。
プロシージャで戻り値とOUTパラメータを返す場合は、ちゃんと仕様書がないとわけのわからないものになる。
前半と後半で違う説明をしているね。
ファンクションは「関数」だ。
OUTパラメータを参照するのは「手続き」という処理だ。
プロシージャで戻り値とOUTパラメータを返す場合は、ちゃんと仕様書がないとわけのわからないものになる。
236デフォルトの名無しさん
2023/08/31(木) 18:27:10.59ID:ZhVoPqIG なんだこの中身のないアホなレスはw
237デフォルトの名無しさん
2023/08/31(木) 23:06:43.05ID:smxtGdye そもそも、ＤＢＭＳの指定や前提もなく
>ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数
とか書いてあるなら、そのサイトに問題があるだけの話
まあ、ちゃんと前提を読んでないか理解してない読み手の問題の可能性もあるが
>ストアドプロシージャって初心者用解説サイトとかで戻り値のない関数
とか書いてあるなら、そのサイトに問題があるだけの話
まあ、ちゃんと前提を読んでないか理解してない読み手の問題の可能性もあるが
238デフォルトの名無しさん
2023/09/01(金) 20:37:48.72ID:5C0TsKNS 関数やプロシージャのことを「メソッド」と書いている書籍もあるくらいだからな。勝手な名前をつけるやつはたくさんいる。
239デフォルトの名無しさん
2023/09/01(金) 23:32:50.20ID:OZcoXz6r ざっくり言うと
ファンクションは1つのSQL文の中でSELECT句やWHERE句などの一部として繰り返し利用する機能を定義したもの
プロシージャはSQL文を使ったひとまとめの処理をSQL文の一部としてではなく外部から繰り返し呼び出せるように定義したもの
これが最も根本的な違い
ファンクションでトランザクション制御しようと考えてしまったりデータベースを更新しようと考えてしまう人はこの根本的違いを理解してない
ファンクションは1つのSQL文の中でSELECT句やWHERE句などの一部として繰り返し利用する機能を定義したもの
プロシージャはSQL文を使ったひとまとめの処理をSQL文の一部としてではなく外部から繰り返し呼び出せるように定義したもの
これが最も根本的な違い
ファンクションでトランザクション制御しようと考えてしまったりデータベースを更新しようと考えてしまう人はこの根本的違いを理解してない
240デフォルトの名無しさん
2023/09/02(土) 22:12:45.21ID:9Zs5bzSj そもそもプロシージャは手続きという処理という意味で、ファンクション(関数)は機能という結果を返す処理の意味。
241デフォルトの名無しさん
2023/09/02(土) 23:45:29.35ID:xVr9+q3l 全然違う
またいい加減なことを言って振り出しに戻すのやめろ
またいい加減なことを言って振り出しに戻すのやめろ
242デフォルトの名無しさん
2023/09/16(土) 22:45:43.61ID:S29731mD 数学がわからないんだろ
243デフォルトの名無しさん
2023/09/16(土) 22:48:52.44ID:S29731mD ファンクションプロシージャは結果を戻り値で返す
サブプロシージャはOUTパラメータ(引数)で返す
SQLの関数は関数(ファンクションプロシージャ)で実装しないとSQLの構文が破綻する
サブプロシージャはOUTパラメータ(引数)で返す
SQLの関数は関数(ファンクションプロシージャ)で実装しないとSQLの構文が破綻する
244デフォルトの名無しさん
2023/09/16(土) 22:55:55.12ID:S29731mD >>241
だから、オラクル社はAda言語をそのまま流用しただけだよ。
ANSIはファンクションの方を先に標準SQLに組み込んだだけ。
ファンクションとサブを区別しているかどうかは、Ada言語を踏襲しているかどうかの違い。
C言語のように戻り値を無視する構文がいいのか悪いのかという話だよ。
だから、オラクル社はAda言語をそのまま流用しただけだよ。
ANSIはファンクションの方を先に標準SQLに組み込んだだけ。
ファンクションとサブを区別しているかどうかは、Ada言語を踏襲しているかどうかの違い。
C言語のように戻り値を無視する構文がいいのか悪いのかという話だよ。
245デフォルトの名無しさん
2023/09/17(日) 13:55:16.79ID:I/olJ+Ch perl の戻り値の仕組みは面白いと思ったのは古い思い出
246デフォルトの名無しさん
2023/09/17(日) 23:44:17.06ID:70jB6wMR noSQLのスレはないの
オブジェクト指向データベースとかはsql使うのかな
オブジェクト指向データベースとかはsql使うのかな
247デフォルトの名無しさん
2023/09/18(月) 11:28:48.80ID:+ud3D/1q noSQLスレは以前はあった
248デフォルトの名無しさん
2023/10/06(金) 19:29:28.75ID:Oy8bZUfG >>246
データベース板を忘れないでください
データベース板を忘れないでください
249デフォルトの名無しさん
2024/04/15(月) 01:05:12.02ID:3rGFgNqt 入門レベルです
環境はsqliteをsqlite3 CLIを通して使ってます
expr(式)を評価して簡易に値を確かめる方法はあったりしませんかね？
目的は学習目的の挙動把握実験と切り分けデバッグです、例えば'foo' LIKE 'f_%'とかそんなやつを試したい
sqlで実行できるのはstmt(文)のみなので、今のところexprを受け付ける何らかのstmt(文)に組み込み、その結果から値を間接的に類推してます
類推するにせよ、そもそもstmt毎に固有の意味論があるゆえ、一貫した振る舞いも得られず
なかなかしんどいです…
それっぽいCLIコマンドの.printも、シグネチャが.print STRING+なのでexpr評価がされませんし
環境はsqliteをsqlite3 CLIを通して使ってます
expr(式)を評価して簡易に値を確かめる方法はあったりしませんかね？
目的は学習目的の挙動把握実験と切り分けデバッグです、例えば'foo' LIKE 'f_%'とかそんなやつを試したい
sqlで実行できるのはstmt(文)のみなので、今のところexprを受け付ける何らかのstmt(文)に組み込み、その結果から値を間接的に類推してます
類推するにせよ、そもそもstmt毎に固有の意味論があるゆえ、一貫した振る舞いも得られず
なかなかしんどいです…
それっぽいCLIコマンドの.printも、シグネチャが.print STRING+なのでexpr評価がされませんし
250デフォルトの名無しさん
2024/04/15(月) 11:17:52.57ID:fSSptXgn >>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
とでも打てばいいだろうよ。でもこれもお前にとっては余計な回り道でしかないから、とっとと進むべきだと思うがな。
> % 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
とでも打てばいいだろうよ。でもこれもお前にとっては余計な回り道でしかないから、とっとと進むべきだと思うがな。
251デフォルトの名無しさん
2024/04/15(月) 12:03:59.29ID:YG3lrvG/ >>250
やはり標準環境には無さそうな感じですか
LIKEはexprの一番簡単な例としてです
実際のところC系等の一般用途のプログラミング言語と比べてsqlのexpr文法って異常に複雑じゃありません？
https://sqlite.org/lang_expr.html
ASTも印字して欲しいくらいだけど、自分でパーサ書いてみるのも勉強になりそうですね
やはり標準環境には無さそうな感じですか
LIKEはexprの一番簡単な例としてです
実際のところC系等の一般用途のプログラミング言語と比べてsqlのexpr文法って異常に複雑じゃありません？
https://sqlite.org/lang_expr.html
ASTも印字して欲しいくらいだけど、自分でパーサ書いてみるのも勉強になりそうですね
252デフォルトの名無しさん
2024/04/15(月) 12:45:09.95ID:cLz3iDP/ 普通の言語はstmtの構成要素としてexprが設けられるが、sqlでは逆にexprの中にstmtも入り得る異色の設計だから、exprサブセットのみの評価機は作れないね
まあstmtの評価は単にモックとして構文木を組んでみれば目的には適うし良い勉強になる
区切り文字をあまり使わないSQLは初学者には目に滑る構文だから特にそう
まあstmtの評価は単にモックとして構文木を組んでみれば目的には適うし良い勉強になる
区切り文字をあまり使わないSQLは初学者には目に滑る構文だから特にそう
253デフォルトの名無しさん
2024/04/15(月) 12:57:20.78ID:cLz3iDP/ >>251
評価の確認はおとなしくSQLiteに投げて、構文解析慣れてるようだし見本はこれ参考で十分だろう
https://sqlite.org/src/artifact/741a270b7f2f85bc
lemonって変わったパーサジェネレータ使ってるのけど、見た感じただのyacc変種なので出会ったトークン種別を単に印字させればよいだけ
評価の確認はおとなしくSQLiteに投げて、構文解析慣れてるようだし見本はこれ参考で十分だろう
https://sqlite.org/src/artifact/741a270b7f2f85bc
lemonって変わったパーサジェネレータ使ってるのけど、見た感じただのyacc変種なので出会ったトークン種別を単に印字させればよいだけ
254デフォルトの名無しさん
2024/04/15(月) 13:34:40.60ID:fSSptXgn >>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では無いが、まあ似たようなものではあるだろう。
> やはり標準環境には無さそうな感じですか
実際要らんしね。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では無いが、まあ似たようなものではあるだろう。
255デフォルトの名無しさん
2024/04/15(月) 14:00:04.64ID:YG3lrvG/ >>252
sqliteの構文図見直したらしっかりselect-stmtってありますねえ…
>>253
まさに求めてたやつです、どうも
各処理系のパーサも見較べるとBison向けでルール/アクションの羅列のpsqlの奴が一番わかり易かった
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y
psql用だけど拡張や高度な機能を気にする段階に無いので、ここから必要そうなのを拾い始めました
sqliteのパーサは中でゴチャゴチャ処理してるけど、psqlのパーサはparser/*.cへアクション内で呼ぶ関数がキレイに分離されていて、記述的命名から意味論まで分かるお手本のようなデザインですね
座右の文法リファレンスとして印刷してそのまま使えそうな出来栄え
sqliteの構文図見直したらしっかりselect-stmtってありますねえ…
>>253
まさに求めてたやつです、どうも
各処理系のパーサも見較べるとBison向けでルール/アクションの羅列のpsqlの奴が一番わかり易かった
https://github.com/postgres/postgres/blob/master/src/backend/parser/gram.y
psql用だけど拡張や高度な機能を気にする段階に無いので、ここから必要そうなのを拾い始めました
sqliteのパーサは中でゴチャゴチャ処理してるけど、psqlのパーサはparser/*.cへアクション内で呼ぶ関数がキレイに分離されていて、記述的命名から意味論まで分かるお手本のようなデザインですね
座右の文法リファレンスとして印刷してそのまま使えそうな出来栄え
256デフォルトの名無しさん
2024/04/15(月) 14:07:24.63ID:YG3lrvG/ >>254
忠告どうも
たまたまSQLという'言語'が面白そうで規格までしっかりある良さそうなもので意欲を得ました
もしこのSQL'言語'が肌に合わなかったならば、プログラミング言語同梱のリレーショナルデータベースAPIへロールバックするでしょう
私の主眼はスレタイ通りSQLにあります
忠告どうも
たまたまSQLという'言語'が面白そうで規格までしっかりある良さそうなもので意欲を得ました
もしこのSQL'言語'が肌に合わなかったならば、プログラミング言語同梱のリレーショナルデータベースAPIへロールバックするでしょう
私の主眼はスレタイ通りSQLにあります
257デフォルトの名無しさん
2024/04/15(月) 14:23:22.62ID:f5jIOgeT 既にRDBバリバリ管理やってる人こそ学ぶべき
むしろ初学が厳しい見た目のSQLだと挫折率高そう
母語に流暢でも英語をサボる理由にはならない
API通ってる環境なら必然的に埋め込みSQLも使える
むしろ初学が厳しい見た目のSQLだと挫折率高そう
母語に流暢でも英語をサボる理由にはならない
API通ってる環境なら必然的に埋め込みSQLも使える
258デフォルトの名無しさん
2024/04/15(月) 14:34:25.57ID:fSSptXgn >>256
そりゃ規格はあるよ。
ただ無料では仕様書が手に入らないらしい。勿論買えば済むらしいが。
> プログラミング言語同梱のリレーショナルデータベースAPI
てかこれ何ぞ？Oracleのことか？
そもそもDB使ってきててSQL知ラネ、ってのがかなり意味不明なのだが。
ORMの事なら、ぶっちゃけORMで済むのならORMでやるべきだと思うよ。
むしろ今時SQL手打ちか？とも言われてるはずだし。
(AccessとかでもクエリビルダーでSQLを作成してて、SQL自体をプログラマが打ち込む必要はなかったはず)
そりゃ規格はあるよ。
ただ無料では仕様書が手に入らないらしい。勿論買えば済むらしいが。
> プログラミング言語同梱のリレーショナルデータベースAPI
てかこれ何ぞ？Oracleのことか？
そもそもDB使ってきててSQL知ラネ、ってのがかなり意味不明なのだが。
ORMの事なら、ぶっちゃけORMで済むのならORMでやるべきだと思うよ。
むしろ今時SQL手打ちか？とも言われてるはずだし。
(AccessとかでもクエリビルダーでSQLを作成してて、SQL自体をプログラマが打ち込む必要はなかったはず)
259デフォルトの名無しさん
2024/04/15(月) 14:57:46.75ID:2Ew9RCgX260デフォルトの名無しさん
2024/04/15(月) 15:02:39.91ID:2Ew9RCgX LINQはRDB以外の色々なデータベースモデルも想定してるからSQLとはかなり違う
LINQでRDB管理に習熟してもSQL知識はあまり付かないと思われ
LINQでRDB管理に習熟してもSQL知識はあまり付かないと思われ
261デフォルトの名無しさん
2024/04/15(月) 16:16:36.38ID:Xey1DMe3 >>249
'foo' LIKE 'f_%'とかを試したいならSELECT 'foo' LIKE ‘f_%’;とすればいい
ただSQLを学ぶ目的なら実際に使うSQLでデータのほうを弄りながらいろいろ試したほうが断然効率いいよ
一つ一つ式の評価結果を実際に使うSQLとは別で確認するのは時間の無駄
https://www.db-fiddle.com/f/oUzwVLEEeWgxdxbQN36kvJ/0
あとプログラマー歴が長い人にありがちだけど
SQLをループと条件節のように命令型のパラダイムで捉えるのはお勧めしない
関係演算の感覚を身につける妨げになるから
'foo' LIKE 'f_%'とかを試したいならSELECT 'foo' LIKE ‘f_%’;とすればいい
ただSQLを学ぶ目的なら実際に使うSQLでデータのほうを弄りながらいろいろ試したほうが断然効率いいよ
一つ一つ式の評価結果を実際に使うSQLとは別で確認するのは時間の無駄
https://www.db-fiddle.com/f/oUzwVLEEeWgxdxbQN36kvJ/0
あとプログラマー歴が長い人にありがちだけど
SQLをループと条件節のように命令型のパラダイムで捉えるのはお勧めしない
関係演算の感覚を身につける妨げになるから
262デフォルトの名無しさん
2024/04/15(月) 16:47:19.47ID:fSSptXgn むう？なんか書き込み失敗して内容も失ったが、覚えてる範囲でもう一度書く。
復活して同様の物が連投されてたらご容赦を。
>>259-260
LINQはSQL風にC#を書ける物で、C#のArrayに対してSQLを発行できるものではなかったと思ったが違ったか？
俺は後者だと思ってたが前者だったので絶望した。あれが有用になる局面がよく分からん。
俺が希望してたLINQ：
.NETのStreamクラスが匿名パイプ/ネットワークストリーム/ファイルの抽象クラスのように、
.NETのArrayや各種DBに対してSQLを発行できるもの
(つまり、接続先がDBなら通常通り、接続先をArrayにすればオンメモリDBとして、同一コードで一文字も変更なく動く物）
実際のLINQ：
for文を書きたくないでござる、だけのクソったれ
俺はあくまでSQLでDB管理する前提で、LINQが何らかのラッパを提供するものだと思ってた。
だから実際のLINQ見て使えねえと判断したが、全く違う方法でDB管理するのかあれは？
俺は勝手に、SQL書けるがC#書けない奴をC#側の戦力として取り込む文法かと思ってたが。
が、まあ、
> プログラミング言語同梱のリレーショナルデータベースAPI
がLINQ等を指すのはわかった。そして ID:YG3lrvG/ の書き込みを読み直すと、
もしかして自前でSQLインタフェース提供しようとしてる？
ならそれは諦めて、DBをPostgreSQL等に移行するほうが妥当だと思うぜ。
復活して同様の物が連投されてたらご容赦を。
>>259-260
LINQはSQL風にC#を書ける物で、C#のArrayに対してSQLを発行できるものではなかったと思ったが違ったか？
俺は後者だと思ってたが前者だったので絶望した。あれが有用になる局面がよく分からん。
俺が希望してたLINQ：
.NETのStreamクラスが匿名パイプ/ネットワークストリーム/ファイルの抽象クラスのように、
.NETのArrayや各種DBに対してSQLを発行できるもの
(つまり、接続先がDBなら通常通り、接続先をArrayにすればオンメモリDBとして、同一コードで一文字も変更なく動く物）
実際のLINQ：
for文を書きたくないでござる、だけのクソったれ
俺はあくまでSQLでDB管理する前提で、LINQが何らかのラッパを提供するものだと思ってた。
だから実際のLINQ見て使えねえと判断したが、全く違う方法でDB管理するのかあれは？
俺は勝手に、SQL書けるがC#書けない奴をC#側の戦力として取り込む文法かと思ってたが。
が、まあ、
> プログラミング言語同梱のリレーショナルデータベースAPI
がLINQ等を指すのはわかった。そして ID:YG3lrvG/ の書き込みを読み直すと、
もしかして自前でSQLインタフェース提供しようとしてる？
ならそれは諦めて、DBをPostgreSQL等に移行するほうが妥当だと思うぜ。
263デフォルトの名無しさん
2024/04/15(月) 18:29:06.40ID:x2iyd0ju >>262
めっちゃくちゃ基本的なこともわかってないからまずは公式チュートリアル的なのを読んだほうがいい
LINQ to ObjectとLINQ to SQL/DataSet/Entitiesの区別くらいは最低限つくようにしてくれ
めっちゃくちゃ基本的なこともわかってないからまずは公式チュートリアル的なのを読んだほうがいい
LINQ to ObjectとLINQ to SQL/DataSet/Entitiesの区別くらいは最低限つくようにしてくれ
264デフォルトの名無しさん
2024/04/15(月) 19:25:10.27ID:fSSptXgn >>263
なるほど俺が糞だと思ってたのはLINQ to Objectなのは分かった。
そして俺の思惑とは違い、MSはSQL対象のほうをラップしてるわけか。
俺的希望仕様ならLINQはリテラルか引数で無ければならず、ハードコードベタ書きとか意味不明だったが、
まあこれなら分からんでも無い。
が、そもそもこれはSQLが無駄に方言が増えすぎてたからMSもLINQというSQLモドキを実装しただけの気がするが。
それでもDOMだXPATHだとやるよりはLINQだけで済む方がいいのは確かだが、
ある意味新たなMSSQL方言を生み出しただけの気も。
そしてOracleもSQL方言だとは聞いてるし、やっぱRDB弄っててSQL知ラネ、ってのはよく分からない。
KVSならSQL関係ないが、そういう感じではなさそうだし。まあいいけどね。
なるほど俺が糞だと思ってたのはLINQ to Objectなのは分かった。
そして俺の思惑とは違い、MSはSQL対象のほうをラップしてるわけか。
俺的希望仕様ならLINQはリテラルか引数で無ければならず、ハードコードベタ書きとか意味不明だったが、
まあこれなら分からんでも無い。
が、そもそもこれはSQLが無駄に方言が増えすぎてたからMSもLINQというSQLモドキを実装しただけの気がするが。
それでもDOMだXPATHだとやるよりはLINQだけで済む方がいいのは確かだが、
ある意味新たなMSSQL方言を生み出しただけの気も。
そしてOracleもSQL方言だとは聞いてるし、やっぱRDB弄っててSQL知ラネ、ってのはよく分からない。
KVSならSQL関係ないが、そういう感じではなさそうだし。まあいいけどね。
265デフォルトの名無しさん
2024/04/16(火) 08:55:41.54ID:Fr3sHPgG LINQはSQLに寄せようとしてる雰囲気があるので中途半端感
普通は言語のインメモリオブジェクト操作の方へ寄せるのだが
C#, VB.NET etc.の多言語前提のデザインだからかな
まあWhereとかSelectとかキーワードを借りて文面ぱっと見だけの話
普通は言語のインメモリオブジェクト操作の方へ寄せるのだが
C#, VB.NET etc.の多言語前提のデザインだからかな
まあWhereとかSelectとかキーワードを借りて文面ぱっと見だけの話
266デフォルトの名無しさん
2024/04/16(火) 10:35:29.23ID:len5k1k5 >>265
MSなりの折衷策なんだろ。
> 言語のインメモリオブジェクト操作の方へ寄せる
これならORMが最上で、それ以上は無いからね。
PHPにはPDOという、無いよりはましだが実質的に意味が無いラッパがあるが、
あれよりはましなDBラッパを用意して、共通文法を考えました、ってところだろ。
実際、forでウダウダやるより宣言型の方が読みやすいのは確かだから、宣言型文法も取り入れたかったのだろうし。
MSなりの折衷策なんだろ。
> 言語のインメモリオブジェクト操作の方へ寄せる
これならORMが最上で、それ以上は無いからね。
PHPにはPDOという、無いよりはましだが実質的に意味が無いラッパがあるが、
あれよりはましなDBラッパを用意して、共通文法を考えました、ってところだろ。
実際、forでウダウダやるより宣言型の方が読みやすいのは確かだから、宣言型文法も取り入れたかったのだろうし。
267デフォルトの名無しさん
2024/09/22(日) 19:26:44.50ID:kkG3ckzv 初歩的なことで申し訳ありませんがご教授ください。
idカラムに例として 5, 7, 11, 41 があります。
41, 11, 7, 5とソートしたいのですが
order by id DESC では、7, 5, 41, 11とソートされます。
なにか良い方法はございますでしょうか。
よろしくお願いします。
idカラムに例として 5, 7, 11, 41 があります。
41, 11, 7, 5とソートしたいのですが
order by id DESC では、7, 5, 41, 11とソートされます。
なにか良い方法はございますでしょうか。
よろしくお願いします。
ORDER BY INT(id) DESC
ではどうでしょう
カラムid が文字列となっていないでしょうか
INTは DBによってことなるかも
上手くいかなかったらごめんなさい
ではどうでしょう
カラムid が文字列となっていないでしょうか
INTは DBによってことなるかも
上手くいかなかったらごめんなさい
269デフォルトの名無しさん
2024/09/23(月) 07:02:58.03ID:dfCQ5A4R いや「初歩的な」と言ってるんだし、
SQLではなく、テーブル作成時の間違いで、
crete table mytable (id INTEGER
とかやれと言った方がいいのでは
SQLではなく、テーブル作成時の間違いで、
crete table mytable (id INTEGER
とかやれと言った方がいいのでは
270デフォルトの名無しさん
2024/09/23(月) 08:28:16.45ID:fL+Xy+IA271デフォルトの名無しさん
2024/09/23(月) 09:03:31.51ID:dfCQ5A4R >>270
> 都合上文字列のカラムなので
嘘だね
でもそのidをTEXTにするのは設計が間違ってるから、早い段階で直しておかないと頓挫する
でなければ壮絶クソコードの山になり、何とか動かせるだけのゴミにしかならないよ
設計的に正しい場合は、そのidが7,5,41,11とソートされて何も問題ないはず
他者の担当部分等の理由で変更出来ないのなら、つまり仕事としてやってるんだろうから、そいつや上司に聞け、ここで聞くのは悪手
(Zは同僚や上司に聞いたら恥とでも思ってるようだが、そうではなく、
部下がどの程度の技術レベルでどこまで仕事振れるかも管理範囲なのだから、分からない事は聞くべきだし、
逆にこの程度の初歩的部分すら分からないのに聞く事も許さないというのは、仕事場/上司に見切り付けるべき
そしてどうしても変更出来ないならCREATE VIEWで誤魔化した方がまだましな気もするが、まあ先に相談だろうね)
だから実際は自分でやってるんだろ、ならさっさとtable定義を直すべき
> 都合上文字列のカラムなので
嘘だね
でもそのidをTEXTにするのは設計が間違ってるから、早い段階で直しておかないと頓挫する
でなければ壮絶クソコードの山になり、何とか動かせるだけのゴミにしかならないよ
設計的に正しい場合は、そのidが7,5,41,11とソートされて何も問題ないはず
他者の担当部分等の理由で変更出来ないのなら、つまり仕事としてやってるんだろうから、そいつや上司に聞け、ここで聞くのは悪手
(Zは同僚や上司に聞いたら恥とでも思ってるようだが、そうではなく、
部下がどの程度の技術レベルでどこまで仕事振れるかも管理範囲なのだから、分からない事は聞くべきだし、
逆にこの程度の初歩的部分すら分からないのに聞く事も許さないというのは、仕事場/上司に見切り付けるべき
そしてどうしても変更出来ないならCREATE VIEWで誤魔化した方がまだましな気もするが、まあ先に相談だろうね)
だから実際は自分でやってるんだろ、ならさっさとtable定義を直すべき
272デフォルトの名無しさん
2024/09/25(水) 13:39:54.41ID:UPZugvt8 バカは放っとこうよ
273デフォルトの名無しさん
2024/10/14(月) 03:33:42.65ID:iqlRL8W8274デフォルトの名無しさん
2024/10/14(月) 03:34:54.50ID:iqlRL8W8 >>270
少なくとも製品名くらいは書こうぜ
少なくとも製品名くらいは書こうぜ
275デフォルトの名無しさん
2024/10/14(月) 12:40:53.49ID:mb36WxU5 >>273
新手のバカが現れたw
新手のバカが現れたw
276デフォルトの名無しさん
2024/10/14(月) 12:49:16.73ID:iqlRL8W8277デフォルトの名無しさん
2024/10/14(月) 12:50:50.99ID:iqlRL8W8 >>275
彼は7、5、4、1の順になってしまうと書いているが、アスキー文字の数字は1が先で9が後に配置されている。
彼は7、5、4、1の順になってしまうと書いているが、アスキー文字の数字は1が先で9が後に配置されている。
278デフォルトの名無しさん
2024/10/14(月) 14:18:28.43ID:/mng7eSx 日本語が読めないのかSQLを全く知らないのかわからんが救いようのないバカなのは間違いない
279デフォルトの名無しさん
2024/10/14(月) 16:02:24.13ID:iqlRL8W8 11を11、41を41、5を05、7を07という風にしないと結果は不明。
280デフォルトの名無しさん
2024/10/27(日) 09:13:31.20ID:Vdu9Rrcz 良い感じのSQLのGUIクライアントある？
たとえばカラムに連番と画像（画像元のパスなど）があって、
全てのがぞうを表示するようなものを求めてる
殆どのGUIクライアントはそういうDBだ画像は表示されなくてその画像部分のフィールドをクリックしたときに1枚だけ表示されるけど、
そうじゃなくてずらっと並んでる画像パスの入ったフィールド全ての画像を表示したいのだが
たとえばカラムに連番と画像（画像元のパスなど）があって、
全てのがぞうを表示するようなものを求めてる
殆どのGUIクライアントはそういうDBだ画像は表示されなくてその画像部分のフィールドをクリックしたときに1枚だけ表示されるけど、
そうじゃなくてずらっと並んでる画像パスの入ったフィールド全ての画像を表示したいのだが
281デフォルトの名無しさん
2024/10/27(日) 09:41:04.89ID:ThFiCQpU 自分で作るか人が作ったアプリのDB構造に合わせるかしないと無理だろ
いずれにしろSQL関係ない
いずれにしろSQL関係ない
282デフォルトの名無しさん
2024/10/27(日) 15:56:39.28ID:Vdu9Rrcz283デフォルトの名無しさん
2024/10/28(月) 15:33:24.71ID:ehQdeP61 >>280
MS-Access
MS-Access
284デフォルトの名無しさん
2024/10/28(月) 16:27:15.25ID:xaz6ouOz >>283
63bitで最大4Gまでしか扱えないものはノーサンキュ
63bitで最大4Gまでしか扱えないものはノーサンキュ
285sage
2024/10/28(月) 17:18:52.43ID:ehQdeP61 これが条件後出しカッコ悪いというやつか
286デフォルトの名無しさん
2024/10/28(月) 17:25:09.25ID:Hp6dJGZ5 63bit 63bit 63bit 63bit
最大4G 最大4G 最大4G 最大4G
最大4G 最大4G 最大4G 最大4G
287デフォルトの名無しさん
2024/10/30(水) 02:07:11.28ID:p9nsrTZ/ evo tech ωωω
288デフォルトの名無しさん
2024/10/30(水) 02:37:36.07ID:BzmMNap8 >>283,285
accessは他の追随を一切赦さぬDBMS覇権（性能、機能的な意味で）だろ
事実上普及してる全てのDBMSにコネクトできる万能クライアントだし
つまり表向きの売りであるGUIガン無視したとてしても最強
GUIでポチポチした履歴と生成されるクエリ突き合わせて解読をつづけれりゃあSQL資料すら見ずともSQL書きの中の上には成れる
惜しむらくはそれだけ優れててもMSに干されそうなとこか…
OfficeからAccess抜いて別売とか正気とは思えんよ、AccessがOfficeに同梱された時は狂喜乱舞してたなあ…
他のAccessフォロワRDBMS環境はOpen/Libre（とその派生）のBaseだけれども、正
直言って...α版の域すら出てないレベルでCLI叩いててSQL直打ちの方がマシ
accessは他の追随を一切赦さぬDBMS覇権（性能、機能的な意味で）だろ
事実上普及してる全てのDBMSにコネクトできる万能クライアントだし
つまり表向きの売りであるGUIガン無視したとてしても最強
GUIでポチポチした履歴と生成されるクエリ突き合わせて解読をつづけれりゃあSQL資料すら見ずともSQL書きの中の上には成れる
惜しむらくはそれだけ優れててもMSに干されそうなとこか…
OfficeからAccess抜いて別売とか正気とは思えんよ、AccessがOfficeに同梱された時は狂喜乱舞してたなあ…
他のAccessフォロワRDBMS環境はOpen/Libre（とその派生）のBaseだけれども、正
直言って...α版の域すら出てないレベルでCLI叩いててSQL直打ちの方がマシ
289デフォルトの名無しさん
2024/10/30(水) 10:40:48.68ID:x/mNM3SS290デフォルトの名無しさん
2024/10/30(水) 19:37:59.35ID:MyBSxte7 >289
自分で作っちゃえばええやん
sqlでselectしてアプリケーション経由して（phpでもjavaでもTypeScriptでも何でもおけ）適当にhtmlブラウザで表示させればええやん
複雑なjoinとか無くて一つのテーブルで済むなら30分も掛からず出来るっしょ
自分で作っちゃえばええやん
sqlでselectしてアプリケーション経由して（phpでもjavaでもTypeScriptでも何でもおけ）適当にhtmlブラウザで表示させればええやん
複雑なjoinとか無くて一つのテーブルで済むなら30分も掛からず出来るっしょ
291デフォルトの名無しさん
2024/10/30(水) 19:51:27.08ID:x/mNM3SS292デフォルトの名無しさん
2024/10/30(水) 19:57:39.75ID:MyBSxte7 >291
マルチやめなさい。そしてhtml表示は一つの手段でしか無い。他にも方法なんぞ幾らでもあるわ。ただし、開発環境を一切書いてないから助言が出来るわけもなく
あくまで一般的な方法で手っ取り早いのを伝えただけ。
Excelのマクロ組んでもいいだろうし、cuiでコマンド叩いてDBからローカルの画像パス取ってきてホストPCに表示するバッチ組んでも良いだろうし…
「結局最終的にはhtmlで表示するしかない」なんて一言も書いてないぞ
繰り返すが「開発環境を一切書いてないから助言が出来るわけもなくあくまで一般的な方法で手っ取り早いのを伝えただけ。」だぞ
マルチやめなさい。そしてhtml表示は一つの手段でしか無い。他にも方法なんぞ幾らでもあるわ。ただし、開発環境を一切書いてないから助言が出来るわけもなく
あくまで一般的な方法で手っ取り早いのを伝えただけ。
Excelのマクロ組んでもいいだろうし、cuiでコマンド叩いてDBからローカルの画像パス取ってきてホストPCに表示するバッチ組んでも良いだろうし…
「結局最終的にはhtmlで表示するしかない」なんて一言も書いてないぞ
繰り返すが「開発環境を一切書いてないから助言が出来るわけもなくあくまで一般的な方法で手っ取り早いのを伝えただけ。」だぞ
293デフォルトの名無しさん
2024/10/30(水) 20:01:18.39ID:x/mNM3SS >>292
そもそもphpでもjavaでもまたひと手間かよと思ったら泣きたくなってよー
とらいえずExcelでのデータベースはできたんだ
ただ数万の画像表示でクッソ重いからファイルパスに変えたけど
でも画像べらーって表示したいじゃん
これを試しに画像だけでもHTMLでやったらどうなるかと思ったら数万枚数十万のサムネ画像べらーっとはったら重いわ
そうなんだよな、htmlしばりするわけじゃねーもんな
とりあえず、EXCELでデータベース作って、SQliteにぶち込んでそれで様子みてる
そっから先は何でどうするか選択肢がおおすぎてわけわからなくなってんだわ
マツリポストは後生やからさぁ、いまのところかんべんしてつかーさい
そもそもphpでもjavaでもまたひと手間かよと思ったら泣きたくなってよー
とらいえずExcelでのデータベースはできたんだ
ただ数万の画像表示でクッソ重いからファイルパスに変えたけど
でも画像べらーって表示したいじゃん
これを試しに画像だけでもHTMLでやったらどうなるかと思ったら数万枚数十万のサムネ画像べらーっとはったら重いわ
そうなんだよな、htmlしばりするわけじゃねーもんな
とりあえず、EXCELでデータベース作って、SQliteにぶち込んでそれで様子みてる
そっから先は何でどうするか選択肢がおおすぎてわけわからなくなってんだわ
マツリポストは後生やからさぁ、いまのところかんべんしてつかーさい
294デフォルトの名無しさん
2024/10/30(水) 20:04:46.88ID:2JaEjh5Z マルチポストとかこんなところにそんなのが存在するのか？
295デフォルトの名無しさん
2024/10/30(水) 20:07:31.52ID:x/mNM3SS 良く考えたら風俗嬢とかのサイトでも女の子すべてずらーっと見せるの無いよな
数十毎にくぎってページ１とか２にしてるわけだし
数十毎にくぎってページ１とか２にしてるわけだし
296デフォルトの名無しさん
2024/10/30(水) 21:20:15.49ID:J5/QLmGD ガイジ大暴れ
297デフォルトの名無しさん
2024/10/31(木) 13:02:50.98ID:POJr+rF8 馬鹿には無理
298デフォルトの名無しさん
2024/11/01(金) 00:10:42.00ID:EQMsSXTB >>291
そんな付加をかけまくるツール、人間が少しだけ見るためのツールに需要はない。
そんな付加をかけまくるツール、人間が少しだけ見るためのツールに需要はない。
299デフォルトの名無しさん
2024/11/01(金) 09:10:10.59ID:xFfDlU+j300デフォルトの名無しさん
2024/11/01(金) 19:58:15.69ID:p+e2Ja+9 つ<img loading="lazy">
てか結局何がしたいの？
explorer＋特大アイコンで駄目な理由は？
てか結局何がしたいの？
explorer＋特大アイコンで駄目な理由は？
301デフォルトの名無しさん
2024/11/01(金) 19:58:32.10ID:TgBKHsuN twitterのフォロワー整理ツールとか参考になるわ
302デフォルトの名無しさん
2024/11/03(日) 17:55:14.49ID:sFUWrMLA >>300
画像がDBに入っていると、エクスプローラーでは見れないんだよね
画像がDBに入っていると、エクスプローラーでは見れないんだよね
303デフォルトの名無しさん
2024/11/03(日) 18:18:24.25ID:gYhGbZOp >>302
それはそうだが、そもそも画像をDBに入れる意味がない
ただ初心者あるあるらしく、「(画像掲示板では)そうじゃなくてファイル名だけDBに入れてapacheに直接配信させるんだ」と
説明してたサイトがあったがすぐには出てこない
なおSQLiteはBLOBにもインデックス張れるらしいが、そんな使い方しないだろ
それはそうだが、そもそも画像をDBに入れる意味がない
ただ初心者あるあるらしく、「(画像掲示板では)そうじゃなくてファイル名だけDBに入れてapacheに直接配信させるんだ」と
説明してたサイトがあったがすぐには出てこない
なおSQLiteはBLOBにもインデックス張れるらしいが、そんな使い方しないだろ
304デフォルトの名無しさん
2024/11/03(日) 18:54:12.64ID:sFUWrMLA305デフォルトの名無しさん
2024/11/03(日) 20:08:56.01ID:gYhGbZOp ないと思うが、まあ上級者なら自分で何とかしろ
なお293なら画像をDBに入れてなければ解決してる
なお293なら画像をDBに入れてなければ解決してる
306デフォルトの名無しさん
2024/11/03(日) 22:39:10.72ID:EvIOUlko 何も解決してないだろｗｗ
307デフォルトの名無しさん
2024/11/04(月) 14:37:07.62ID:odwm0TPR ずっとBAD GATEWAY
308デフォルトの名無しさん
2024/11/04(月) 14:37:49.34ID:odwm0TPR っつーのは書けるのか なんてこった
解決しなきゃいけない案件じゃねーだろ 画面いっぱいに数万もの大量な画像をずらーっと表示したいなんて要望は
そも、それをしてからその先どうしたいんだ？ それを一向に書こうとしない相談者に難がある
表示したらそれで満足なんか？
ランダムに表示するようにでもしなきゃ、毎回その数万の画像のうち特定の一部だけを目撃することに成る それに意味は？
小アイコンサイズで画面いっぱいに貼ったとしてFHDモニタで250枚程度だ もっとちっさくした画像でも貼ろうってのか
いろんな画像が次々湧いてくるようなエフェクト掛けて、とかならDBだのSQLだのほぼほぼ関係ねーわ
解決しなきゃいけない案件じゃねーだろ 画面いっぱいに数万もの大量な画像をずらーっと表示したいなんて要望は
そも、それをしてからその先どうしたいんだ？ それを一向に書こうとしない相談者に難がある
表示したらそれで満足なんか？
ランダムに表示するようにでもしなきゃ、毎回その数万の画像のうち特定の一部だけを目撃することに成る それに意味は？
小アイコンサイズで画面いっぱいに貼ったとしてFHDモニタで250枚程度だ もっとちっさくした画像でも貼ろうってのか
いろんな画像が次々湧いてくるようなエフェクト掛けて、とかならDBだのSQLだのほぼほぼ関係ねーわ
309デフォルトの名無しさん
2024/11/04(月) 14:52:26.31ID:1xi3Twsq >>308
何も解決していないのに「なお293なら画像をDBに入れてなければ解決してる(ｷﾘｯ)」みたいな痛いレスが面白かっただけだよ
何も解決していないのに「なお293なら画像をDBに入れてなければ解決してる(ｷﾘｯ)」みたいな痛いレスが面白かっただけだよ
310デフォルトの名無しさん
2024/11/06(水) 08:23:55.64ID:spMsN6R2 >>299
RDBでデータ型が画像データというデータ型は聞いたことがない。
RDBは画像データのバイナリデータか、画像データファイル形式に近いラージオブジェクト型。
単に画像データファイルへのリンクが入っているだけという設計もある。
RDBでデータ型が画像データというデータ型は聞いたことがない。
RDBは画像データのバイナリデータか、画像データファイル形式に近いラージオブジェクト型。
単に画像データファイルへのリンクが入っているだけという設計もある。
311デフォルトの名無しさん
2024/11/06(水) 08:54:43.24ID:L0rogwPJ INNER JOINとEXISTSどっちがいいんだ？
312デフォルトの名無しさん
2024/11/06(水) 10:46:12.80ID:2mRFCI0/ 使い途がちがう EXISTSはture/falseを返すだけ
313デフォルトの名無しさん
2024/11/06(水) 11:02:31.90ID:L0rogwPJ INNER JOINでもWHERE EXISTSでも、テーブルBのデータを使ってテーブルAのデータを絞り込んでSELECTするができるじゃん
性能的にどっちがいいんだっていう
性能的にどっちがいいんだっていう
314デフォルトの名無しさん
2024/11/06(水) 12:00:06.03ID:spMsN6R2315デフォルトの名無しさん
2024/11/06(水) 12:02:25.42ID:spMsN6R2317デフォルトの名無しさん
2024/11/12(火) 08:43:58.73ID:ZCUDlG+O PostgreSQL 17 を使ってるんですが
SELECT shohin_bunrui AS aaa
FROM shohin
where aaa = '衣服';
↑実行順序を考えると当然エラーになります。
エラー: 列"aaa"は存在しません
SELECT shohin_bunrui AS aaa
FROM shohin
GROUP BY aaa;
↑エラーになりません。SELECTよりGROUP BYの方が実行順が先なのになぜですか？
SELECT shohin_bunrui AS aaa
FROM shohin
where aaa = '衣服';
↑実行順序を考えると当然エラーになります。
エラー: 列"aaa"は存在しません
SELECT shohin_bunrui AS aaa
FROM shohin
GROUP BY aaa;
↑エラーになりません。SELECTよりGROUP BYの方が実行順が先なのになぜですか？
抽出条件で行の絞り込みをするのは、SELECTでなく WHEREかと
行を絞ってからグループ化するのはそうかもしれないけど、
統一感はあった方がいいとは思いますね
行を絞ってからグループ化するのはそうかもしれないけど、
統一感はあった方がいいとは思いますね
319デフォルトの名無しさん
2024/11/12(火) 11:00:57.73ID:jB7P5Kru320317
2024/11/12(火) 12:30:43.18ID:ZCUDlG+O >> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
321317
2024/11/12(火) 12:30:43.35ID:ZCUDlG+O >> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
322317
2024/11/12(火) 12:30:44.59ID:ZCUDlG+O >> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。
323デフォルトの名無しさん
2024/11/12(火) 12:31:48.29ID:ZCUDlG+O すみません。ブラウザの反応がなかったので何回も書込み押してしまいました
324デフォルトの名無しさん
2024/11/12(火) 15:44:40.37ID:3FuqnzdR view造って先にaaaのみにするんじゃね
326デフォルトの名無しさん
2024/11/12(火) 17:29:22.04ID:v7TGFNyn >>322
そんなに列別名を使いたい理由がわからない。
集合演算のSELECTでテーブルによって列名が異なるならやらないといけないが、そういうSELECTでないのにテーブル別名メリットが大きいが、列別名を使うメリットなんてほとんどないよ。
そんなに列別名を使いたい理由がわからない。
集合演算のSELECTでテーブルによって列名が異なるならやらないといけないが、そういうSELECTでないのにテーブル別名メリットが大きいが、列別名を使うメリットなんてほとんどないよ。
327デフォルトの名無しさん
2024/11/12(火) 17:31:02.65ID:v7TGFNyn >>325
SQLの構文解析エンジンの仕様によるような書き方をするのがそもそもの間違いだよね。
SQLの構文解析エンジンの仕様によるような書き方をするのがそもそもの間違いだよね。
>>327
ですね
ですね
LINQを最初に見たとき、なんでこんな順序なんだ? と思ったけど、自然な順序なのかもね
FROM→WHERE→SELECT
しばらくLINQやってないから、うろ覚えで見当違いだったらごめんなさい
FROM→WHERE→SELECT
しばらくLINQやってないから、うろ覚えで見当違いだったらごめんなさい
330デフォルトの名無しさん
2024/11/12(火) 19:58:46.82ID:v7TGFNyn331デフォルトの名無しさん
2024/12/20(金) 16:41:43.73ID:cA4MHukG テーブルごと全てのカラムにまとめて別名付けるとかできないのかな
以下のような場合に別名付けるとき
テーブルA
id
name
description
テーブルB
id
name
description
select
A.id as A_id,
A.name as A_name,
A.description as A_description,
B.id as B_id,
B.name as B_name,
B.description as B_description
from
みたいに書かないといけないのを
A.* as A_*
みたいに書けたら便利なのに
以下のような場合に別名付けるとき
テーブルA
id
name
description
テーブルB
id
name
description
select
A.id as A_id,
A.name as A_name,
A.description as A_description,
B.id as B_id,
B.name as B_name,
B.description as B_description
from
みたいに書かないといけないのを
A.* as A_*
みたいに書けたら便利なのに
332デフォルトの名無しさん
2024/12/21(土) 11:36:41.92ID:KZIgeCwE うちはそのまま A.name のまま扱ってるよ
333デフォルトの名無しさん
2024/12/21(土) 19:55:23.41ID:IOryZJAZ >>331
またそのネタかよw
またそのネタかよw
334デフォルトの名無しさん
2024/12/21(土) 20:43:39.23ID:SDOaO/8s SQLを出力するプログラム位かけるやろ
336デフォルトの名無しさん
2024/12/23(月) 10:17:08.30ID:xh1kOIEb >>333
また、って言うくらいには結構求められている機能だと思う
また、って言うくらいには結構求められている機能だと思う
337デフォルトの名無しさん
2024/12/23(月) 18:35:45.31ID:GjEN+y4a >>329
LINQはそもそも.NETのコードの物だから
メソッドチェーンで書く時の順番がそのままになってるだけよ
HogeList.Where().Select()って書き方になるからクエリ式もそうなる。
LINQはそもそも.NETのコードの物だから
メソッドチェーンで書く時の順番がそのままになってるだけよ
HogeList.Where().Select()って書き方になるからクエリ式もそうなる。
338デフォルトの名無しさん
2024/12/24(火) 09:46:38.33ID:MemH7BuO >>331
すべてのカラムに最初からそういう名前をつけているよ
テーブルA
A_id
A_name
A_description
テーブルB
B_id
B_name
B_description
select
A_id,
A_name,
A_description,
B_id,
B_name,
B_description
from
とシンプルに書けて良いよ
すべてのカラムに最初からそういう名前をつけているよ
テーブルA
A_id
A_name
A_description
テーブルB
B_id
B_name
B_description
select
A_id,
A_name,
A_description,
B_id,
B_name,
B_description
from
とシンプルに書けて良いよ
339デフォルトの名無しさん
2024/12/24(火) 12:30:30.62ID:V4/fVU02 >338
>331を読むに、別名（エイリアス）でテーブル名付けたいって事でしょ
確かに長ったらしいテーブル名は一括で一文字のエイリアス名を付けたいな…の思う事もあるから>338の言わんとしてることも分かる
>331を読むに、別名（エイリアス）でテーブル名付けたいって事でしょ
確かに長ったらしいテーブル名は一括で一文字のエイリアス名を付けたいな…の思う事もあるから>338の言わんとしてることも分かる
340デフォルトの名無しさん
2024/12/24(火) 22:39:03.73ID:S4CkJ4V1 >>335
標示SQLではSELECTよりもWITHが先
標示SQLではSELECTよりもWITHが先
341デフォルトの名無しさん
2024/12/24(火) 22:40:09.34ID:S4CkJ4V1 >>338
同じカラム名なのに意味が異なるという狂った設計なのが間違い
同じカラム名なのに意味が異なるという狂った設計なのが間違い
342デフォルトの名無しさん
2024/12/25(水) 01:30:11.46ID:YXgPFPfq SQLというよりSQL clientの機能の話じゃね？
SELECT a.id, a.name, b.id, b.name FROM foo a INNER JOIN bar b ON …
↑みたいなクエリを書いた時に結果のカラム名が単にid, name, id, nameと表示されるのではなくa.id, a.name, b.id, b.nameと表示されればいいわけでしょ？
プログラムから結果セットにアクセスする時は”a.id”や”b.id”でアクセスするんだから表示調整くらい簡単にできそうだけどな
SELECT a.id, a.name, b.id, b.name FROM foo a INNER JOIN bar b ON …
↑みたいなクエリを書いた時に結果のカラム名が単にid, name, id, nameと表示されるのではなくa.id, a.name, b.id, b.nameと表示されればいいわけでしょ？
プログラムから結果セットにアクセスする時は”a.id”や”b.id”でアクセスするんだから表示調整くらい簡単にできそうだけどな
343デフォルトの名無しさん
2024/12/25(水) 08:15:20.48ID:63Wcp4qk 誰もWITHの話なんかしとらんのに突然の主張ｗ
344デフォルトの名無しさん
2024/12/25(水) 12:26:11.92ID:wfmvBy7R 日本語SQLスズラン
345デフォルトの名無しさん
2024/12/25(水) 15:26:23.80ID:PDJSnv/I be with you
346デフォルトの名無しさん
2024/12/25(水) 17:53:18.64ID:YmcCoB80 >>343
SELECT句よりも先にWITH句を書くので、SELECT句が先ではない。
SELECT句よりも先にWITH句を書くので、SELECT句が先ではない。
347デフォルトの名無しさん
2024/12/25(水) 17:56:53.42ID:YmcCoB80 >>342
根本的に同じカラム名なのに別のカラムという設計がおかしい
どちらかのテーブルにしかないカラムなら、修飾そのものがいらない
それはあんたはSQLの話ではなくて、別の製品の仕様の話をしている
それに同じ名前のカラム名なら別名を定義するべきだ
根本的に同じカラム名なのに別のカラムという設計がおかしい
どちらかのテーブルにしかないカラムなら、修飾そのものがいらない
それはあんたはSQLの話ではなくて、別の製品の仕様の話をしている
それに同じ名前のカラム名なら別名を定義するべきだ
348デフォルトの名無しさん
2024/12/25(水) 17:58:44.64ID:YmcCoB80SQLを適当に書く人間が増えて、めちゃくちゃなシステムだらけになった。
同じカラムが、同じカラムがというなら、結合したビューでも用意しとけよw
349デフォルトの名無しさん
2024/12/25(水) 18:33:32.24ID:WXVFxdaX 元の話も読めないようなヤツはWITHがどうのと主張しとらんと黙っといた方がいいよｗ
350デフォルトの名無しさん
2024/12/25(水) 18:36:08.08ID:63Wcp4qk >>346
誰もWITHの話なんかしとらんのに突然の主張ｗ
誰もWITHの話なんかしとらんのに突然の主張ｗ
351デフォルトの名無しさん
2024/12/25(水) 19:42:44.67ID:r1WXKMXg352デフォルトの名無しさん
2024/12/25(水) 19:44:16.65ID:r1WXKMXg353デフォルトの名無しさん
2024/12/25(水) 19:47:55.88ID:r1WXKMXg 「クエリ式」はSQLの世界の話ではなく、SQLを組み立てる側のライブラリの世界の話。
使われる方が使う方を意識するという発想で設計書を書かせようとする人間がいるが、それだと延々とドキュメントを修正することになる。
世界中の人間に聞いて回ってドキュメントを修正するなど無理だし、無意味。
使われる方が使う方を意識するという発想で設計書を書かせようとする人間がいるが、それだと延々とドキュメントを修正することになる。
世界中の人間に聞いて回ってドキュメントを修正するなど無理だし、無意味。
354デフォルトの名無しさん
2024/12/25(水) 21:03:35.85ID:WXVFxdaX ダメだわこの頭でっかちｗ
355デフォルトの名無しさん
2024/12/26(木) 13:44:41.34ID:KwPCWpVD >>341
うれしい副産物として、違うカラム名にできるというメリットもある
うれしい副産物として、違うカラム名にできるというメリットもある
356デフォルトの名無しさん
2024/12/30(月) 02:42:59.39ID:SuC1UiOz357デフォルトの名無しさん
2024/12/30(月) 02:44:55.46ID:SuC1UiOz なぜ「データベース」板を無視して「プログラム」板に書いているのも謎
358デフォルトの名無しさん
2024/12/30(月) 14:22:49.66ID:y1s4zo7f SQLなんて一回描いたら何度も描き治すもんでもないからな
面倒臭がるのは怠慢
面倒臭がるのは怠慢
359デフォルトの名無しさん
2024/12/30(月) 19:29:38.65ID:V3PHz5v0 >>358
なおすでーー
なおすでーー
360デフォルトの名無しさん
2025/01/01(水) 21:42:25.49ID:sxxQrAOo >>359
そう何度も直すことは無いよ
そう何度も直すことは無いよ
361デフォルトの名無しさん
2025/01/01(水) 23:12:26.15ID:21eIb2Fa へぼかったら治すでーー
362デフォルトの名無しさん
2025/01/05(日) 10:38:54.01ID:c9RkuEF2 単にテキストエディタの機能を使いこなせずに毎度、すべてキー入力している初心者は案外、多い。
363デフォルトの名無しさん
2025/01/05(日) 10:48:34.28ID:8kdOFrcZ ORMなんていらん
364デフォルトの名無しさん
2025/01/05(日) 19:51:54.27ID:ToFXQ1cV サブクエリ難しい
365デフォルトの名無しさん
2025/01/05(日) 19:52:23.20ID:ToFXQ1cV 息をするようにSQLを書きたい
366デフォルトの名無しさん
2025/01/05(日) 20:49:47.84ID:ktpqqLIO367デフォルトの名無しさん
2025/01/05(日) 22:36:32.88ID:Gf5gTRAY CTEのおかげてサブクエリの出番はめっきり少なくなったよね
368デフォルトの名無しさん
2025/01/06(月) 12:33:31.51ID:HkxXvSmh >>367
ＣＴＥってなに？
ＣＴＥってなに？
369デフォルトの名無しさん
2025/01/06(月) 18:37:10.53ID:xyyiC8Hr >>366
ありがとう
やってみる
逆にそれでサブクエリの感覚が掴めるかもしれないと勝手な期待をしている
accessとExcelVBAでやっているけど、IT素人のPC好きなおじさんがやる
やってるから何分感覚がつかめない
ミックさんのデータベース入門は読んでいるけど読み切れていない
ありがとう
やってみる
逆にそれでサブクエリの感覚が掴めるかもしれないと勝手な期待をしている
accessとExcelVBAでやっているけど、IT素人のPC好きなおじさんがやる
やってるから何分感覚がつかめない
ミックさんのデータベース入門は読んでいるけど読み切れていない
370デフォルトの名無しさん
2025/01/06(月) 20:05:07.43ID:PWtKQBnB >>369
そうそう、その視点や観点が本当に大事
プログラム全般そうだけど一気に書こうとするとスパゲティ化して自分でも訳わからなくなるから
必ず最小から始めて、それらをくっ付けて大きくしていくみたいな感覚が大事
そうそう、その視点や観点が本当に大事
プログラム全般そうだけど一気に書こうとするとスパゲティ化して自分でも訳わからなくなるから
必ず最小から始めて、それらをくっ付けて大きくしていくみたいな感覚が大事
371デフォルトの名無しさん
2025/01/09(木) 00:01:55.02ID:8WDo/TAk サブクエリは普通に使うだろ
372デフォルトの名無しさん
2025/01/11(土) 10:22:19.58ID:ouBpeDRU サブクエリを使うクエリを分解したらたいていN+1になるしな
373デフォルトの名無しさん
2025/01/19(日) 01:50:01.24ID:IALgBqxE サブクエリ使う理由ってめんどくさがったり一時領域をケチる以外に理由ないよ
サブクエリを使わずに結果を出すようにした方がメンテもパフォーマンスも上がる
サブクエリを使わずに結果を出すようにした方がメンテもパフォーマンスも上がる
374デフォルトの名無しさん
2025/01/19(日) 02:17:21.82ID:9/Z57kyd サブクエリの有無ごときで議論になるの笑ってしまうなw
どんなちっこいアプリなんだ？電卓とか？
どんなちっこいアプリなんだ？電卓とか？
375デフォルトの名無しさん
2025/01/19(日) 06:33:56.88ID:ugzsMDEi 1週間も経って突然貶し始める方が笑ってしまうわ
376デフォルトの名無しさん
2025/01/19(日) 09:51:50.41ID:pfUoPKo5 どこの句のどういう使い方をするサブクエリなのか書いてくれないと、サブクエリを使うべきなのか、そうでないか答えようがない。
378デフォルトの名無しさん
2025/01/19(日) 16:06:56.18ID:vo12PcwL トランザクションを指定すれば？
379デフォルトの名無しさん
2025/01/19(日) 16:20:11.02ID:MoFiVYUu そこはSQLを複数回に分割して発行するかどうかよりも上位のレベルで
トランザクションや同時実行制御の観点から設計しておくべき事項
担保する必要性の有無は分割しようがしまいが変わらない
トランザクションや同時実行制御の観点から設計しておくべき事項
担保する必要性の有無は分割しようがしまいが変わらない
382デフォルトの名無しさん
2025/01/20(月) 11:39:20.74ID:7SyPOdKK サブクエリを使わないで、一旦チンポテーブルに書き出す方式があったよね
あれなんだっけか
あれなんだっけか
次の3つのフィールドで構成される複合主キーがあり
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
384デフォルトの名無しさん
2025/01/20(月) 18:55:00.26ID:kikzz/Vc キーのバラつき具合やオプティマイザの機能にもよるから一概に不要とも作成すべきとも言えない
385デフォルトの名無しさん
2025/01/20(月) 18:55:26.16ID:kikzz/Vc 実際のクエリプランを見て判断
ありがとうございます>>383です
ちなみにaccessです
ちなみにaccessです
>>3々3です
accessで複合主キーを設定したとき、インデックスは自動で付与されるでしょうか
accessで複合主キーを設定したとき、インデックスは自動で付与されるでしょうか
388デフォルトの名無しさん
2025/01/21(火) 08:53:02.94ID:9Kz0tqcV インデックスじゃない主キーってなんだ……。
>>388
調べてみるとそうみたいなんだけど(主キーにはインデックスが張られる)、単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
それがどういうことか(インデックスが張られているか)分からなくて
分かりにくくてごめんね
調べてみるとそうみたいなんだけど(主キーにはインデックスが張られる)、単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
それがどういうことか(インデックスが張られているか)分からなくて
分かりにくくてごめんね
390デフォルトの名無しさん
2025/01/21(火) 11:15:04.33ID:+xYYoS0+ >>389
DBの構成上、主キーであれば最低限１つのインデックスは張られる
それはPK1,PK2,PK3全部揃ったときにB木を辿れればいいだけなので、6(=3P3)通りのどれかだが、
何もなければ PK1->PK2->PK3 の1つのインデックスになる
この場合、PK1,PK2 のセットならインデックスが使えるが、今回のように PK2, Pk3 のセットだと使えない
これはクエリプランを見れば判断出来る
SQLiteだとこのケースでは上記の通り
というかCREATE INDEX時(CREATE TABLE時)に使われ方を予測する事は不可能なので、
DBとしては、記述通りPK1->PK2->PK3で一つ作るか、全組み合わせを作っておくかしか出来ない
よく使われる検索に対して自動的にインデックスを作成して高速化してくれるDBがあるのかもしれんが俺は知らん
DBの構成上、主キーであれば最低限１つのインデックスは張られる
それはPK1,PK2,PK3全部揃ったときにB木を辿れればいいだけなので、6(=3P3)通りのどれかだが、
何もなければ PK1->PK2->PK3 の1つのインデックスになる
この場合、PK1,PK2 のセットならインデックスが使えるが、今回のように PK2, Pk3 のセットだと使えない
これはクエリプランを見れば判断出来る
SQLiteだとこのケースでは上記の通り
というかCREATE INDEX時(CREATE TABLE時)に使われ方を予測する事は不可能なので、
DBとしては、記述通りPK1->PK2->PK3で一つ作るか、全組み合わせを作っておくかしか出来ない
よく使われる検索に対して自動的にインデックスを作成して高速化してくれるDBがあるのかもしれんが俺は知らん
391デフォルトの名無しさん
2025/01/21(火) 11:23:25.76ID:+xYYoS0+ >>389
> 単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
これは少し勘違いしてる
インデックスはあくまでB木であって、個々のフィールドやカラムとは全く別物
インデックスが当たってるかは、クエリプランで確認すべき事
> 単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
これは少し勘違いしてる
インデックスはあくまでB木であって、個々のフィールドやカラムとは全く別物
インデックスが当たってるかは、クエリプランで確認すべき事
>>389です
ありがとうございます
(以下Accessです)
新たにテーブルに、主キー(PK1,PK2,PK3)を作成した段階で数万件のレコードを入れ、仮に(PK1,PK3)をキーとしてSELECTで抽出をするとめちゃくちゃ遅い…(1)
上のテーブルの主キーの個々のフィールド(3つ)にインデックスを設定して(1)と同じ条件の抽出をするとかなり速い…(2)
(2)のインデックスを削除して主キーと同じフィールドに複合インデックスを設定するともっと速い…(3)
(1):(2):(3)=65:1.5:1
くらいの比率でした
主キーを設定しただけではとても遅かったです(65倍)
なにか設定・前提に誤りがあるかもしれません
ありがとうございます
(以下Accessです)
新たにテーブルに、主キー(PK1,PK2,PK3)を作成した段階で数万件のレコードを入れ、仮に(PK1,PK3)をキーとしてSELECTで抽出をするとめちゃくちゃ遅い…(1)
上のテーブルの主キーの個々のフィールド(3つ)にインデックスを設定して(1)と同じ条件の抽出をするとかなり速い…(2)
(2)のインデックスを削除して主キーと同じフィールドに複合インデックスを設定するともっと速い…(3)
(1):(2):(3)=65:1.5:1
くらいの比率でした
主キーを設定しただけではとても遅かったです(65倍)
なにか設定・前提に誤りがあるかもしれません
394デフォルトの名無しさん
2025/01/21(火) 16:54:19.10ID:c07BxmkO >>394
すみません、ちょっと投稿内容に誤りがありました
(1)の複合主キーと、(3)の複合インデックスをまったく同じフィールド、個数、順序とすると、(1)と同じように、複合主キーのみでインデックスを設定しないときの同じように65倍の時間が掛かりました
デフォルトで設定されたインデックスと一致しているので当然なのかもしれません
先ほどの(3)の結果としてを得たのは、試行錯誤して複合インデックスから検索キーとしないフィールドを削除したもので、複合主キーのフィールド数より2つ少ないです
後出しになりすみません
データの内容によっても結果は変わるでしょうし、オレ環なので諦めるしかないかなと
すみません、ちょっと投稿内容に誤りがありました
(1)の複合主キーと、(3)の複合インデックスをまったく同じフィールド、個数、順序とすると、(1)と同じように、複合主キーのみでインデックスを設定しないときの同じように65倍の時間が掛かりました
デフォルトで設定されたインデックスと一致しているので当然なのかもしれません
先ほどの(3)の結果としてを得たのは、試行錯誤して複合インデックスから検索キーとしないフィールドを削除したもので、複合主キーのフィールド数より2つ少ないです
後出しになりすみません
データの内容によっても結果は変わるでしょうし、オレ環なので諦めるしかないかなと
397デフォルトの名無しさん
2025/01/22(水) 00:08:11.72ID:l3OLrM1a {PK1,PK2,PK3}で複合キーが定義されてる場合
検索条件が{PK1}か{PK1, PK2}か{PK1, PK2, PK3}であればどのDBMSでも大半のケースでインデックスが使われる
検索条件が{PK1, PK3}の場合はPK1のselectivity次第でインデックスが使われるものがある
検索条件が{PK2, PK3}のように一番左のカラムが含まれない場合はindex skip scanという機能が実装されてなければインデックスは使われない(Accessにはたぶん実装されてない)
他のクエリとの兼ね合いで複合主キーを構成するカラムの順序を変更できないということであれば該当クエリ用に複合インデックスを追加するのは妥当
検索条件が{PK1}か{PK1, PK2}か{PK1, PK2, PK3}であればどのDBMSでも大半のケースでインデックスが使われる
検索条件が{PK1, PK3}の場合はPK1のselectivity次第でインデックスが使われるものがある
検索条件が{PK2, PK3}のように一番左のカラムが含まれない場合はindex skip scanという機能が実装されてなければインデックスは使われない(Accessにはたぶん実装されてない)
他のクエリとの兼ね合いで複合主キーを構成するカラムの順序を変更できないということであれば該当クエリ用に複合インデックスを追加するのは妥当
398デフォルトの名無しさん
2025/01/22(水) 00:28:31.31ID:VcBzYOin >>396
というか何がやりたいのか不明な事になってるが、
> 検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
であれば遅い(＝インデックスがない)と分かったのだからインデックス作ればいいだけでは
>>393
> 多分見方が分かりませんがw
見方なんて分かる必要なくて、
1. インデックスがある検索に対してクエリプランを出させる(＝インデックス検索)
2. インデックスがない検索に対してクエリプランを出させる（＝リニア探索)
3. 実際に自分がやりたい検索が、1,2のどちらに似てるか見る、特に先頭付近
ただインデックスが何で、どうやってDBがレコードを抽出してくるのか分かってなさそうなので、1,2が出来ない気もするが
結果で確認したければ、正しくインデックスが作成された後は、
α. SELECT * FROM mytable WHERE PK1=a AND PK2=b AND PK3=c;
β. SELECT * FROM mytable WHERE PK2=b AND PK3=c;
でαとβはほぼ同速になるはずだよ
というか何がやりたいのか不明な事になってるが、
> 検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
であれば遅い(＝インデックスがない)と分かったのだからインデックス作ればいいだけでは
>>393
> 多分見方が分かりませんがw
見方なんて分かる必要なくて、
1. インデックスがある検索に対してクエリプランを出させる(＝インデックス検索)
2. インデックスがない検索に対してクエリプランを出させる（＝リニア探索)
3. 実際に自分がやりたい検索が、1,2のどちらに似てるか見る、特に先頭付近
ただインデックスが何で、どうやってDBがレコードを抽出してくるのか分かってなさそうなので、1,2が出来ない気もするが
結果で確認したければ、正しくインデックスが作成された後は、
α. SELECT * FROM mytable WHERE PK1=a AND PK2=b AND PK3=c;
β. SELECT * FROM mytable WHERE PK2=b AND PK3=c;
でαとβはほぼ同速になるはずだよ
400デフォルトの名無しさん
2025/01/22(水) 01:53:19.83ID:IIgBVdb4 そもそもＡＣＣＥＳＳのクエリプラントとか、取得大変だがな
401デフォルトの名無しさん
2025/01/22(水) 05:04:07.48ID:xghKhcgN ACCESSにクエリプランなんてあるん？ｗ
ファイルで配布できる必要があるとかじゃなければ、MS SQL Expressなり使った方がやりやすくない？
昔と違ってGUIツールも今は無料配布になってるし。
ファイルで配布できる必要があるとかじゃなければ、MS SQL Expressなり使った方がやりやすくない？
昔と違ってGUIツールも今は無料配布になってるし。
402デフォルトの名無しさん
2025/01/22(水) 07:08:36.05ID:VcBzYOin >>399
> 最左のカラムを検索キーとするかがポイントなんですね
違う。というか理由を理解ではなく結果を暗記しようとする辺り、文系馬鹿の匂いがするが、
とにかく、「B木」でググって記事を読め
現在のプログラミングでは基本で、そこそこ初心者が記事を書くネタになってるから、いくらでも出てくる
そしてVBAにもハッシュはあるだろ。ググるとScripting.Dictionaryと出てくるが、中身は同様にB木のはずだから、
何か知らんが速いという事で済まさず、この機会にちゃんと理解しろ
そしてその言い方なら、
左側が全部揃ってるかがポイント
が正解になる
ただ、遅くて困るのならインデックス張ればいいだけではあるが
> 最左のカラムを検索キーとするかがポイントなんですね
違う。というか理由を理解ではなく結果を暗記しようとする辺り、文系馬鹿の匂いがするが、
とにかく、「B木」でググって記事を読め
現在のプログラミングでは基本で、そこそこ初心者が記事を書くネタになってるから、いくらでも出てくる
そしてVBAにもハッシュはあるだろ。ググるとScripting.Dictionaryと出てくるが、中身は同様にB木のはずだから、
何か知らんが速いという事で済まさず、この機会にちゃんと理解しろ
そしてその言い方なら、
左側が全部揃ってるかがポイント
が正解になる
ただ、遅くて困るのならインデックス張ればいいだけではあるが
>>402
ありがとうございます
B木の「B」はBinaryでなくBalanceだったのですね
B木の深さは複合キーの個数で一定となるツリーなんですね
二分木をイメージして「??」でしたが、B木の構造がイメージできればインデックスの効果が得られるか否かが分かりやすいと思いました
ありがとうございます
B木の「B」はBinaryでなくBalanceだったのですね
B木の深さは複合キーの個数で一定となるツリーなんですね
二分木をイメージして「??」でしたが、B木の構造がイメージできればインデックスの効果が得られるか否かが分かりやすいと思いました
404デフォルトの名無しさん
2025/01/22(水) 10:44:07.12ID:VcBzYOin >>403
> 二分木をイメージして「??」でしたが
いやそういう問題じゃない
というか相変わらずインデックスが何かさっぱり分かってないようだが、単なるリーフへの探索手段だぞ
実際はこんなキーの分け方はあり得ないが、馬鹿でも分かるように敢えて例とすると、
お前が名詞を1,000枚持ってて、あいうえお順に格納して保管してるとする
これは主キーが複合キーの{PK1:苗字1文字目, PK2:苗字2文字目以降, PK3:名前}として、
石破茂を{'石','破','茂'},
岸田文雄を{'岸','田','文雄'}
と格納されてる状態と見なせる
これに対して、{PK2,PK3}の検索、例えば{'田',’茂'}では全く使い物にならないのは分かるだろ。これがインデックスが機能してない状況
同様に、{PK1,PK3}の{'吉','茂'}も無理ゲーと分かるだろ。これもインデックスが機能してない状況
逆に、{PK1,PK2}の検索、{'鈴','木'}なら範囲を確定させられるだろ。これがインデックスが機能してる状況
というか言っちゃ悪いがVBA+accessってプログラマではなくExcel職人上がりも多いのでこの空回りなのだと思うが、
実際、Excel職人ならこの辺理解せずすっ飛ばして「遅いからインデックス張る」で済ませていい
プログラマなら、ちゃんと理解しろ。「赤黒木」とかもお前には有用だろうよ
> 二分木をイメージして「??」でしたが
いやそういう問題じゃない
というか相変わらずインデックスが何かさっぱり分かってないようだが、単なるリーフへの探索手段だぞ
実際はこんなキーの分け方はあり得ないが、馬鹿でも分かるように敢えて例とすると、
お前が名詞を1,000枚持ってて、あいうえお順に格納して保管してるとする
これは主キーが複合キーの{PK1:苗字1文字目, PK2:苗字2文字目以降, PK3:名前}として、
石破茂を{'石','破','茂'},
岸田文雄を{'岸','田','文雄'}
と格納されてる状態と見なせる
これに対して、{PK2,PK3}の検索、例えば{'田',’茂'}では全く使い物にならないのは分かるだろ。これがインデックスが機能してない状況
同様に、{PK1,PK3}の{'吉','茂'}も無理ゲーと分かるだろ。これもインデックスが機能してない状況
逆に、{PK1,PK2}の検索、{'鈴','木'}なら範囲を確定させられるだろ。これがインデックスが機能してる状況
というか言っちゃ悪いがVBA+accessってプログラマではなくExcel職人上がりも多いのでこの空回りなのだと思うが、
実際、Excel職人ならこの辺理解せずすっ飛ばして「遅いからインデックス張る」で済ませていい
プログラマなら、ちゃんと理解しろ。「赤黒木」とかもお前には有用だろうよ
B木については知らなかったが、今回の複合インデックスの件について二分木は論外だとは分かっています
ちなみに、>>402ハッシュの中身がB木というのは自分の認識と異なります
字面でうまく伝わらない部分はあったと思いますが、B木を知ることができ(あえて理解とは言わない)よかったです
ありがとうございました
ちなみに、>>402ハッシュの中身がB木というのは自分の認識と異なります
字面でうまく伝わらない部分はあったと思いますが、B木を知ることができ(あえて理解とは言わない)よかったです
ありがとうございました
406デフォルトの名無しさん
2025/01/22(水) 11:07:43.80ID:s+SsM2Gu 中途半端な知識で間違ったことばっかり書いてるのに
人を馬鹿する自称バカではない理系おじさんは少し自重したほうがいい
人を馬鹿する自称バカではない理系おじさんは少し自重したほうがいい
408デフォルトの名無しさん
2025/01/22(水) 11:27:27.98ID:VcBzYOin >>405
> 今回の複合インデックスの件について二分木は論外だとは分かっています
いやそうじゃねえ
そもそも論外でもないし、インデックスが二分木でも問題ないし、この場合には二分木もB木の一種だよ
B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
まあ君に理解する気がないのは分かったし、実際に理解しなくても済む人達も大勢居るのも事実
ただプログラマならどのみちいつか引っかかるから、この機会にちゃんと理解しといた方が得だぞという話
君がどうするかは君が決める事
> 今回の複合インデックスの件について二分木は論外だとは分かっています
いやそうじゃねえ
そもそも論外でもないし、インデックスが二分木でも問題ないし、この場合には二分木もB木の一種だよ
B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
まあ君に理解する気がないのは分かったし、実際に理解しなくても済む人達も大勢居るのも事実
ただプログラマならどのみちいつか引っかかるから、この機会にちゃんと理解しといた方が得だぞという話
君がどうするかは君が決める事
409デフォルトの名無しさん
2025/01/22(水) 11:42:36.84ID:a9tNcWhf >B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
君が論外
君が論外
410デフォルトの名無しさん
2025/01/22(水) 12:42:33.57ID:VcBzYOin >>407,409
そうじゃない、というかそこは問題ではない
というのが分からないのが問題なのだろうが、君は全てを「具象」で捉えて「暗記」してるだけだろ、これは典型的な文系のやり方
本来は「抽象」で捉えて「理解」しないといけない項目
「B木」も「二分木」も(昔ながらのハッシュ関数を使った)「ハッシュ」も別物ではなくて、
同一の物を分類してるだけ、しかも直交もしてない
話を戻すと、問題は、
・DBのインデックス動作が分からない
・どうインデックスが作成されるかも分からないし、
・どういうクエリならインデックスが使われるのかも分からない
なんだろ
正攻法：（＝プログラマ向け)
・インデックスの実装の仕方(の一つ)を理解する
これにより、インデックスに何が必要か、インデックスで何が出来、何が出来ないかを直感的に判断出来るようになる
(実際の実装では高速化の為にあれこれやってるだろうが、これは今回の目的に対しては全くどうでもいい事)
迂回策：
・クエリプランで毎回確認する
とはいえ読めるのかあれ？
あれを読む努力をするくらいなら、上記のインデックスを理解する努力の方が実になるはず
その上で、このDBではどうなのか？の判断の為に使うものだろあれは
迂回策次善案：（＝Excel職人向け)
・クエリが遅い場合はインデックスを作るようにする
だと思うよ
まあ実際Excel職人っぽいしどうぞお好きにだが、
でも今回理解しておかないと次回以降も同じ所で引っかかり続けるだけだから、
それが嫌なら数時間～数日かけてでもこの機会に理解するしかないでしょ
そうじゃない、というかそこは問題ではない
というのが分からないのが問題なのだろうが、君は全てを「具象」で捉えて「暗記」してるだけだろ、これは典型的な文系のやり方
本来は「抽象」で捉えて「理解」しないといけない項目
「B木」も「二分木」も(昔ながらのハッシュ関数を使った)「ハッシュ」も別物ではなくて、
同一の物を分類してるだけ、しかも直交もしてない
話を戻すと、問題は、
・DBのインデックス動作が分からない
・どうインデックスが作成されるかも分からないし、
・どういうクエリならインデックスが使われるのかも分からない
なんだろ
正攻法：（＝プログラマ向け)
・インデックスの実装の仕方(の一つ)を理解する
これにより、インデックスに何が必要か、インデックスで何が出来、何が出来ないかを直感的に判断出来るようになる
(実際の実装では高速化の為にあれこれやってるだろうが、これは今回の目的に対しては全くどうでもいい事)
迂回策：
・クエリプランで毎回確認する
とはいえ読めるのかあれ？
あれを読む努力をするくらいなら、上記のインデックスを理解する努力の方が実になるはず
その上で、このDBではどうなのか？の判断の為に使うものだろあれは
迂回策次善案：（＝Excel職人向け)
・クエリが遅い場合はインデックスを作るようにする
だと思うよ
まあ実際Excel職人っぽいしどうぞお好きにだが、
でも今回理解しておかないと次回以降も同じ所で引っかかり続けるだけだから、
それが嫌なら数時間～数日かけてでもこの機会に理解するしかないでしょ
411デフォルトの名無しさん
2025/01/22(水) 12:49:28.79ID:VcBzYOin >>410訂正
× 同一の物
○ 同種の物
無駄に絡まれそうなので念のため
まあ俺がどう論外である事を証明したところで、
君がインデックスを理解する事には繋がらないよ
君は努力の方向を間違ってる
(ネットにはこのタイプも多いけども)
× 同一の物
○ 同種の物
無駄に絡まれそうなので念のため
まあ俺がどう論外である事を証明したところで、
君がインデックスを理解する事には繋がらないよ
君は努力の方向を間違ってる
(ネットにはこのタイプも多いけども)
412デフォルトの名無しさん
2025/01/22(水) 13:23:48.02ID:0peR6PAs どんなにアスペな言い訳しようが君がバカだという事実に変わりはないよ
>>405です
途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
414デフォルトの名無しさん
2025/01/22(水) 18:46:15.47ID:VcBzYOin >>413
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄
> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)
とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき
例えばさ、>>383に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄
> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)
とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき
例えばさ、>>383に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ
415デフォルトの名無しさん
2025/01/22(水) 21:30:12.00ID:o3lkJXbH おっさん、文章が長いな。もっと簡潔に書きなさい。あなたの文章にインデックス貼ってクエリもチューニングした方が良いぞ
416デフォルトの名無しさん
2025/01/22(水) 23:15:16.32ID:J/9pPL5e 絵に書いたような老害だなｗ
417デフォルトの名無しさん
2025/01/22(水) 23:17:45.52ID:J/9pPL5e ありゃ「描いた」だぞと老害に指摘されそうだなｗ
418デフォルトの名無しさん
2025/01/22(水) 23:29:43.66ID:I1bb5L41 老害でも技術力があれば匿名掲示板では役立つけどどう見てもないから救いようがない
絶対干されてるタイプ
絶対干されてるタイプ
419デフォルトの名無しさん
2025/01/23(木) 19:03:57.14ID:0iiPrNry どうでもいいけど、制約とインデックスを同一として扱ってるのがモヤるわ
ユニーク制約と主キー制約をインデックスで処理しないＤＢＭＳはみたことないとしても
ユニーク制約と主キー制約をインデックスで処理しないＤＢＭＳはみたことないとしても
420デフォルトの名無しさん
2025/01/23(木) 19:56:56.31ID:hJ60cV1T お前の方が色々混同してそうだが
さ…さすが〜!
し…知らなかった〜!
す…すごーい!
せ…センスい〜ぃ!
そ…そうなんだ〜!
(「合コンさしすせそ」より)
し…知らなかった〜!
す…すごーい!
せ…センスい〜ぃ!
そ…そうなんだ〜!
(「合コンさしすせそ」より)
422デフォルトの名無しさん
2025/01/23(木) 23:29:29.44ID:rNgwBkvb 制約の話で思い出したがAccessの場合は
foreign key制約を設定すればインデックスが自動で出来たはず
(PK1, PK2, PK3)で構成される複合主キーがあって
検索キーとして(PK2, PK3)を利用したいということなら
PK1と(PK2, PK3)は違う親テーブルから主キーを引き継いでるんだろうから
そこにインデックスを張らないという選択はほぼ無いな
foreign key制約を設定すればインデックスが自動で出来たはず
(PK1, PK2, PK3)で構成される複合主キーがあって
検索キーとして(PK2, PK3)を利用したいということなら
PK1と(PK2, PK3)は違う親テーブルから主キーを引き継いでるんだろうから
そこにインデックスを張らないという選択はほぼ無いな
423デフォルトの名無しさん
2025/01/24(金) 04:28:21.32ID:agkokgy5 383以降を見る限り、そんな高級な話ではなく、まるっきり分かってなかっただけだろ
そして(PK2,PK3,PK1)と出来なかった理由の推定なら、そこは(PK1,PK2)とPK3とくくるべき
そして(PK2,PK3,PK1)と出来なかった理由の推定なら、そこは(PK1,PK2)とPK3とくくるべき
424デフォルトの名無しさん
2025/01/24(金) 11:19:27.52ID:SzuokRLj 分かってないのになぜ無理して絡もうとするのが
425デフォルトの名無しさん
2025/02/03(月) 18:36:54.12ID:hEyRnoXc PostgreSQLを使っているのですが、
更新前のデータも参照したいので、
更新処理を、元のデータに変更を加えたデータを追記し、更新元のデータに最新ではないフラグを付ける形でやっています。
新しくカラムを追加したのですが、更新処理の変更を忘れて、更新すると新しいカラムがデフォルト値に戻されてしまうバグを作ってしまいました。
既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
更新前のデータも参照したいので、
更新処理を、元のデータに変更を加えたデータを追記し、更新元のデータに最新ではないフラグを付ける形でやっています。
新しくカラムを追加したのですが、更新処理の変更を忘れて、更新すると新しいカラムがデフォルト値に戻されてしまうバグを作ってしまいました。
既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
426デフォルトの名無しさん
2025/02/03(月) 23:14:40.68ID:k1KW9LUA >>425
>既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
この質問はバグにより作成されたデータの復旧作業方法として質問してる？
それとも一般的にそういう方法ないかということ？
あるいはカラム追加やカラム名の変更があっても更新処理のSQLを修正しなくてもいいようにする方法を聞いてる？
>更新前のデータも参照したいので、
ここで言いってる”参照”は外部キーとして他のテーブルから参照するという意味？
それとも単に更新履歴が閲覧できればいいという意味？
>既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
この質問はバグにより作成されたデータの復旧作業方法として質問してる？
それとも一般的にそういう方法ないかということ？
あるいはカラム追加やカラム名の変更があっても更新処理のSQLを修正しなくてもいいようにする方法を聞いてる？
>更新前のデータも参照したいので、
ここで言いってる”参照”は外部キーとして他のテーブルから参照するという意味？
それとも単に更新履歴が閲覧できればいいという意味？
427デフォルトの名無しさん
2025/02/06(木) 00:29:05.51ID:4njYbkok428デフォルトの名無しさん
2025/02/07(金) 21:07:33.75ID:lNWVt+S0 >>425
トリガーというものがあります
トリガーというものがあります
429デフォルトの名無しさん
2025/02/07(金) 21:08:11.88ID:lNWVt+S0430デフォルトの名無しさん
2025/02/07(金) 22:21:05.36ID:mS2jfvem むしろトリガーの変更を忘れてバグったんじゃないの？
431デフォルトの名無しさん
2025/02/07(金) 23:13:03.59ID:El81lTJA > PostgreSQLでは、トリガ動作として、ユーザ定義関数の実行しか認めていません。
> 標準では、多数の他のSQLコマンドを実行させることができます。
> 例えば、トリガ動作としてCREATE TABLEを実行させることも可能です。
> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
糞仕様杉ワロタ
> 標準では、多数の他のSQLコマンドを実行させることができます。
> 例えば、トリガ動作としてCREATE TABLEを実行させることも可能です。
> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
糞仕様杉ワロタ
432デフォルトの名無しさん
2025/02/08(土) 11:50:00.86ID:+3qBIV3v > この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
この方針は正しいと思うけどな
こういうセキュリティに敏感な場所は出入口を一ヶ所に絞るのは基本だよ
この方針は正しいと思うけどな
こういうセキュリティに敏感な場所は出入口を一ヶ所に絞るのは基本だよ
433デフォルトの名無しさん
2025/02/08(土) 12:46:18.46ID:3VVdck+P いや色々おかしいよお前、多分DB板出身だろうから帰れ
逆に質問者もDB屋ならDB板の方が合ってるとも思うが
逆に質問者もDB屋ならDB板の方が合ってるとも思うが
434デフォルトの名無しさん
2025/02/08(土) 13:11:35.92ID:fsW85FYF 正しいわけないだろｗ
Postgresの仕組み的に関数化が必要なら内部的にラップしとけばいいだけ
実行権限をトリガに対して設定できないとか非標準を維持し続けるほど大した意味はない
Postgresの仕組み的に関数化が必要なら内部的にラップしとけばいいだけ
実行権限をトリガに対して設定できないとか非標準を維持し続けるほど大した意味はない
435デフォルトの名無しさん
2025/02/09(日) 03:19:16.45ID:BAiRqfzU ここの人らはNoSQLはどういう扱いなの
436デフォルトの名無しさん
2025/02/09(日) 12:18:58.85ID:kD9FDD3o 俺個人としては同じDB枠の扱い
プライマリキーやインデックス等、DBとしての使い方は同じで、
それを設定する言語が、SQLか、或いは一般プログラミング言語か、という程度だから
だからこのスレも俺には「DBなら俺に訊け」でもいいんだが、このスレはテンプレないんだな
俺が主流派かどうかは分からない
SQLじゃないとヤダ、って奴が多ければスレを分けるべきだろうが、
正直分けるほど人いないし、NoSQLもここで聞いていいのでは？答える奴が居るかは知らんが
ただ、383も425も、SQLではなく、DBを分かってないから話がおかしくなってるので、
実質SQLではなくDBの質問になってるし、NoSQLでも結果的に同じだと思うよ
個別DBに特化した話等なら、DB板に行った方がいい
ただ、DB板の連中はプログラミングをしない/出来ないようなので、
432のように、プログラマから見たら明らかにトンチンカンな回答が返ってくる
それでもDB固有の問題には詳しいだろうよ
プライマリキーやインデックス等、DBとしての使い方は同じで、
それを設定する言語が、SQLか、或いは一般プログラミング言語か、という程度だから
だからこのスレも俺には「DBなら俺に訊け」でもいいんだが、このスレはテンプレないんだな
俺が主流派かどうかは分からない
SQLじゃないとヤダ、って奴が多ければスレを分けるべきだろうが、
正直分けるほど人いないし、NoSQLもここで聞いていいのでは？答える奴が居るかは知らんが
ただ、383も425も、SQLではなく、DBを分かってないから話がおかしくなってるので、
実質SQLではなくDBの質問になってるし、NoSQLでも結果的に同じだと思うよ
個別DBに特化した話等なら、DB板に行った方がいい
ただ、DB板の連中はプログラミングをしない/出来ないようなので、
432のように、プログラマから見たら明らかにトンチンカンな回答が返ってくる
それでもDB固有の問題には詳しいだろうよ
437デフォルトの名無しさん
2025/02/09(日) 18:18:30.19ID:qhqoX22r >>431
トリガーそのものにロジックは必要ないとしてトリガーを仕様に取り込んだせいでそうなっただけ
トリガーそのものにロジックは必要ないとしてトリガーを仕様に取り込んだせいでそうなっただけ
438デフォルトの名無しさん
2025/02/09(日) 18:19:47.93ID:qhqoX22r >>434
Oracle以外はあとからOracleDBに追従したから、元のクソ仕様のせいで制限がたくさんある。
Oracle以外はあとからOracleDBに追従したから、元のクソ仕様のせいで制限がたくさんある。
439デフォルトの名無しさん
2025/02/09(日) 18:31:02.14ID:mMq7ancL 出た！
DB板の荒らし
通称ボラクル君w
DB板の荒らし
通称ボラクル君w
440デフォルトの名無しさん
2025/02/09(日) 22:11:42.79ID:uTje1YE2441デフォルトの名無しさん
2025/02/09(日) 22:42:05.59ID:JhqniwEL ならお前が正しいと思うことを書けばよいだけでは？
442デフォルトの名無しさん
2025/02/10(月) 00:33:14.69ID:VZ2XQokR nosqlは独自に覚えなきゃいけないことが多すぎるうえに制約も多い
awsとazureで同じ設計が通じるわけでもないし
awsとazureで同じ設計が通じるわけでもないし
443デフォルトの名無しさん
2025/02/10(月) 11:53:19.06ID:Z13/KCo3 KVSですね判ります
444デフォルトの名無しさん
2025/02/10(月) 12:41:14.64ID:y2n5AJNm ベンダー違っても中身は全部Redisという場合もあるし単純なセッション管理にKVSを使うとかならベンダー違っても基本的に同じ設計になるしユースケース次第でいろいろ
NoSQLって言うだけだとリレーショナルじゃないくらいの意味しかなくて広すぎるから細かい話は一括りにはできない
NoSQLって言うだけだとリレーショナルじゃないくらいの意味しかなくて広すぎるから細かい話は一括りにはできない
445デフォルトの名無しさん
2025/05/11(日) 23:41:50.22ID:SmeYoeAy ミックさんの達人SQLは名著だと思うんだけど、関係が体であるとしている点については、群ですらないというamazonレビューの指摘の方が正しいように思うんだよね。ただ自分は文系で群とかちゃんと勉強したことないのであまり自信はない。数学できる人教えて。
446デフォルトの名無しさん
2025/05/12(月) 19:12:28.13ID:RxQ7/dSc >>445
集合は数学とは違うよ
集合は数学とは違うよ
447デフォルトの名無しさん
2025/05/13(火) 14:41:24.56ID:C/NhftFY SQLで無限集合出来んかな
448デフォルトの名無しさん
2025/05/14(水) 00:52:49.17ID:qxlPxgMn なんで havingとwhereは使い分ける必要があるの？
全部whereで済むように仕様を直してほしい
全部whereで済むように仕様を直してほしい
449デフォルトの名無しさん
2025/05/14(水) 01:47:48.71ID:tUJULNxS 意味違うと思うぞ。whereだけじゃ足りないんじゃね
450デフォルトの名無しさん
2025/05/14(水) 01:55:11.10ID:tUJULNxS 評価対象が行とグループ
評価タイミングも違うとchatGPTが教えてくれた
評価タイミングも違うとchatGPTが教えてくれた
451デフォルトの名無しさん
2025/05/14(水) 06:22:22.00ID:qNLCsgAG そんなこともAIに訊かなきゃわからないんかよｗ
452デフォルトの名無しさん
2025/05/14(水) 08:46:47.35ID:e7a03hqN スレ主じゃないので
LLM勉強になるぞ
LLM勉強になるぞ
453デフォルトの名無しさん
2025/05/14(水) 11:40:16.61ID:Ran/8XYC グループ化と関係なくHAVINGを使っているんだろうなw
454デフォルトの名無しさん
2025/05/14(水) 11:41:17.83ID:Ran/8XYC >>452
AIチャットは間違いを指摘してくれない
AIチャットは間違いを指摘してくれない
455デフォルトの名無しさん
2025/05/14(水) 12:56:57.46ID:1iop83U8 LLMの勉強する前に対人会話の勉強しよう？
456デフォルトの名無しさん
2025/05/14(水) 13:29:13.49ID:e7a03hqN お前らもﾈﾗｰだからLLMと大差ないぞ
教科書レベルの話はLLMさんが正確さ
教科書レベルの話はLLMさんが正確さ
457デフォルトの名無しさん
2025/05/15(木) 09:52:35.44ID:3t3KbsMR 結局、>>445ってどう？ 素人考えでは、群の条件のうち、「任意の元に対する逆元が存在する（逆元も関係の元である必要がある）」を、関係および関係上の演算は満たさないようにも思うんだけど。
レスを投稿する
ニュース
- 【音楽】Perfume・あ～ちゃんの結婚相手「一般男性」は吉田カバンの社長・吉田幸裕氏(41) 高身長で山本耕史似 [Ailuropoda melanoleuca★]
- 【サッカー】U-17日本代表、激闘PK戦制す 北朝鮮撃破で6大会ぶり8強入り U17W杯 [久太郎★]
- 【サッカー】日本代表、ボリビアに3発快勝 森保監督通算100試合目を飾る…鎌田、町野、中村がゴール [久太郎★]
- 【インバウンド】中国人観光客の日本での消費額は年間約2兆円超…中国政府は公務員の出張取り消し [１ゲットロボ★]
- XやChatGPTで広範囲の通信障害 投稿や閲覧できず [蚤の市★]
- 【芸能】日中関係悪化でエンタメ業界に大ダメージ… JO1の中国でのイベント中止、邦画は公開延期、STARTOアイドルへの影響も [冬月記者★]
- 石井ちゃんです！
- 職場の俺のあだ名がブロリーなんだが
- アンケート調査で「高市発言は問題なし」 93.5%ｗｗｗｗwｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ [279254606]
- お前らは“スカイマイルタワー”建設計画を知っているか？
- これ誰か分かるか？
- 万引きJC「すいません許してください！何でもしますから！」←どうする？