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

**デフォルトの名無しさん** · 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も使える

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

>>256
そりゃ規格はあるよ。
ただ無料では仕様書が手に入らないらしい。勿論買えば済むらしいが。

> プログラミング言語同梱のリレーショナルデータベースAPI
てかこれ何ぞ？Oracleのことか？
そもそもDB使ってきててSQL知ラネ、ってのがかなり意味不明なのだが。
ORMの事なら、ぶっちゃけORMで済むのならORMでやるべきだと思うよ。
むしろ今時SQL手打ちか？とも言われてるはずだし。
(AccessとかでもクエリビルダーでSQLを作成してて、SQL自体をプログラマが打ち込む必要はなかったはず)

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

>>258
標準ライブラリ備えてるような言語には大抵RDB接続機能があって、ホストの文法に沿ってクエリ送れるやろ
例えば.NET共通のLINQとか
.NET言語毎にもあったりしてそれこそ無数

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

LINQはRDB以外の色々なデータベースモデルも想定してるからSQLとはかなり違う
LINQでRDB管理に習熟してもSQL知識はあまり付かないと思われ

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

>>249
'foo' LIKE 'f_%'とかを試したいならSELECT 'foo' LIKE ‘f_%’;とすればいい
ただSQLを学ぶ目的なら実際に使うSQLでデータのほうを弄りながらいろいろ試したほうが断然効率いいよ
一つ一つ式の評価結果を実際に使うSQLとは別で確認するのは時間の無駄
https://www.db-fiddle.com/f/oUzwVLEEeWgxdxbQN36kvJ/0

あとプログラマー歴が長い人にありがちだけど
SQLをループと条件節のように命令型のパラダイムで捉えるのはお勧めしない
関係演算の感覚を身につける妨げになるから

**デフォルトの名無しさん** · 2024/04/15(月) 16:47:19.47

むう？なんか書き込み失敗して内容も失ったが、覚えてる範囲でもう一度書く。
復活して同様の物が連投されてたらご容赦を。

>>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等に移行するほうが妥当だと思うぜ。

**デフォルトの名無しさん** · 2024/04/15(月) 18:29:06.40

>>262
めっちゃくちゃ基本的なこともわかってないからまずは公式チュートリアル的なのを読んだほうがいい
LINQ to ObjectとLINQ to SQL/DataSet/Entitiesの区別くらいは最低限つくようにしてくれ

**デフォルトの名無しさん** · 2024/04/15(月) 19:25:10.27

>>263
なるほど俺が糞だと思ってたのはLINQ to Objectなのは分かった。
そして俺の思惑とは違い、MSはSQL対象のほうをラップしてるわけか。
俺的希望仕様ならLINQはリテラルか引数で無ければならず、ハードコードベタ書きとか意味不明だったが、
まあこれなら分からんでも無い。

が、そもそもこれはSQLが無駄に方言が増えすぎてたからMSもLINQというSQLモドキを実装しただけの気がするが。
それでもDOMだXPATHだとやるよりはLINQだけで済む方がいいのは確かだが、
ある意味新たなMSSQL方言を生み出しただけの気も。
そしてOracleもSQL方言だとは聞いてるし、やっぱRDB弄っててSQL知ラネ、ってのはよく分からない。
KVSならSQL関係ないが、そういう感じではなさそうだし。まあいいけどね。

**デフォルトの名無しさん** · 2024/04/16(火) 08:55:41.54

LINQはSQLに寄せようとしてる雰囲気があるので中途半端感
普通は言語のインメモリオブジェクト操作の方へ寄せるのだが
C#, VB.NET etc.の多言語前提のデザインだからかな

まあWhereとかSelectとかキーワードを借りて文面ぱっと見だけの話

**デフォルトの名無しさん** · 2024/04/16(火) 10:35:29.23

>>265
MSなりの折衷策なんだろ。

> 言語のインメモリオブジェクト操作の方へ寄せる
これならORMが最上で、それ以上は無いからね。

PHPにはPDOという、無いよりはましだが実質的に意味が無いラッパがあるが、
あれよりはましなDBラッパを用意して、共通文法を考えました、ってところだろ。
実際、forでウダウダやるより宣言型の方が読みやすいのは確かだから、宣言型文法も取り入れたかったのだろうし。

**デフォルトの名無しさん** · 2024/09/22(日) 19:26:44.50

初歩的なことで申し訳ありませんがご教授ください。
idカラムに例として　5, 7, 11, 41 があります。
41, 11, 7, 5とソートしたいのですが
order by id DESC では、7, 5, 41, 11とソートされます。
なにか良い方法はございますでしょうか。
よろしくお願いします。

警備員[Lv.1][新芽] · 2024/09/22(日) 20:32:30.58

ORDER BY INT(id) DESC
ではどうでしょう
カラムid が文字列となっていないでしょうか

INTは DBによってことなるかも
上手くいかなかったらごめんなさい

**デフォルトの名無しさん** · 2024/09/23(月) 07:02:58.03

いや「初歩的な」と言ってるんだし、
SQLではなく、テーブル作成時の間違いで、

crete table mytable (id INTEGER

とかやれと言った方がいいのでは

**デフォルトの名無しさん** · 2024/09/23(月) 08:28:16.45

>>268さん
ありがとうございます！記述は異なりますが、キャストというヒントから実現できました！
助かります！

>>269さん
ありがとうございます。都合上文字列のカラムなので困っていました。
ありがとうございます！

**デフォルトの名無しさん** · 2024/09/23(月) 09:03:31.51

>>270
> 都合上文字列のカラムなので
嘘だね
でもそのidをTEXTにするのは設計が間違ってるから、早い段階で直しておかないと頓挫する
でなければ壮絶クソコードの山になり、何とか動かせるだけのゴミにしかならないよ

設計的に正しい場合は、そのidが7,5,41,11とソートされて何も問題ないはず
他者の担当部分等の理由で変更出来ないのなら、つまり仕事としてやってるんだろうから、そいつや上司に聞け、ここで聞くのは悪手
(Zは同僚や上司に聞いたら恥とでも思ってるようだが、そうではなく、
部下がどの程度の技術レベルでどこまで仕事振れるかも管理範囲なのだから、分からない事は聞くべきだし、
逆にこの程度の初歩的部分すら分からないのに聞く事も許さないというのは、仕事場/上司に見切り付けるべき
そしてどうしても変更出来ないならCREATE VIEWで誤魔化した方がまだましな気もするが、まあ先に相談だろうね)

だから実際は自分でやってるんだろ、ならさっさとtable定義を直すべき

**デフォルトの名無しさん** · 2024/09/25(水) 13:39:54.41

バカは放っとこうよ

**デフォルトの名無しさん** · 2024/10/14(月) 03:33:42.65

>>267
それは文字の照合順序の問題
自分でそうしたのか、他人がそうしたのか書いてないが、一文字目だけで並び替えているだけ。

**デフォルトの名無しさん** · 2024/10/14(月) 03:34:54.50

>>270
少なくとも製品名くらいは書こうぜ

**デフォルトの名無しさん** · 2024/10/14(月) 12:40:53.49

>>273
新手のバカが現れたw

**デフォルトの名無しさん** · 2024/10/14(月) 12:49:16.73

>>275
文字列は文字コード順になるのが普通

桁数の違う数字列を比較したから、どういう結果になるかは照合順序による

数字列と数値は別物

**デフォルトの名無しさん** · 2024/10/14(月) 12:50:50.99

>>275
彼は7、5、4、1の順になってしまうと書いているが、アスキー文字の数字は1が先で9が後に配置されている。

**デフォルトの名無しさん** · 2024/10/14(月) 14:18:28.43

日本語が読めないのかSQLを全く知らないのかわからんが救いようのないバカなのは間違いない

**デフォルトの名無しさん** · 2024/10/14(月) 16:02:24.13

11を11、41を41、5を05、7を07という風にしないと結果は不明。

**デフォルトの名無しさん** · 2024/10/27(日) 09:13:31.20

良い感じのSQLのGUIクライアントある？
たとえばカラムに連番と画像（画像元のパスなど）があって、
全てのがぞうを表示するようなものを求めてる
殆どのGUIクライアントはそういうDBだ画像は表示されなくてその画像部分のフィールドをクリックしたときに1枚だけ表示されるけど、
そうじゃなくてずらっと並んでる画像パスの入ったフィールド全ての画像を表示したいのだが

**デフォルトの名無しさん** · 2024/10/27(日) 09:41:04.89

自分で作るか人が作ったアプリのDB構造に合わせるかしないと無理だろ
いずれにしろSQL関係ない

**デフォルトの名無しさん** · 2024/10/27(日) 15:56:39.28

>>281
ふーん、やっぱそうなるんだ
それを知りたかったんでね
あと何かむかつくからここから俺がこのスレ乗っ取ることにするわ
日記帳がわりにする

**デフォルトの名無しさん** · 2024/10/28(月) 15:33:24.71

>>280
MS-Access

**デフォルトの名無しさん** · 2024/10/28(月) 16:27:15.25

>>283
63bitで最大4Gまでしか扱えないものはノーサンキュ

**sage** · 2024/10/28(月) 17:18:52.43

これが条件後出しカッコ悪いというやつか

**デフォルトの名無しさん** · 2024/10/28(月) 17:25:09.25

63bit　63bit　63bit　63bit
最大4G　最大4G　最大4G　最大4G

**デフォルトの名無しさん** · 2024/10/30(水) 02:07:11.28

evo tech ωωω

**デフォルトの名無しさん** · 2024/10/30(水) 02:37:36.07

>>283,285
accessは他の追随を一切赦さぬDBMS覇権（性能、機能的な意味で）だろ
事実上普及してる全てのDBMSにコネクトできる万能クライアントだし
つまり表向きの売りであるGUIガン無視したとてしても最強
GUIでポチポチした履歴と生成されるクエリ突き合わせて解読をつづけれりゃあSQL資料すら見ずともSQL書きの中の上には成れる

惜しむらくはそれだけ優れててもMSに干されそうなとこか…
OfficeからAccess抜いて別売とか正気とは思えんよ、AccessがOfficeに同梱された時は狂喜乱舞してたなあ…

他のAccessフォロワRDBMS環境はOpen/Libre（とその派生）のBaseだけれども、正
直言って...α版の域すら出てないレベルでCLI叩いててSQL直打ちの方がマシ

**デフォルトの名無しさん** · 2024/10/30(水) 10:40:48.68

DBのGUIでつまいこういうことをやりたい
（ただ表示する画像はもっと多い）

https://i.imgur.com/e5UznLk.png

**デフォルトの名無しさん** · 2024/10/30(水) 19:37:59.35

>289
自分で作っちゃえばええやん
sqlでselectしてアプリケーション経由して（phpでもjavaでもTypeScriptでも何でもおけ）適当にhtmlブラウザで表示させればええやん
複雑なjoinとか無くて一つのテーブルで済むなら30分も掛からず出来るっしょ

**デフォルトの名無しさん** · 2024/10/30(水) 19:51:27.08

>>290
結局最終的にはhtmlで出力しかないのか
DBのGUIでずらっと画像だしてくれるものだとおもってた

**デフォルトの名無しさん** · 2024/10/30(水) 19:57:39.75

>291
マルチやめなさい。そしてhtml表示は一つの手段でしか無い。他にも方法なんぞ幾らでもあるわ。ただし、開発環境を一切書いてないから助言が出来るわけもなく
あくまで一般的な方法で手っ取り早いのを伝えただけ。
Excelのマクロ組んでもいいだろうし、cuiでコマンド叩いてDBからローカルの画像パス取ってきてホストPCに表示するバッチ組んでも良いだろうし…
「結局最終的にはhtmlで表示するしかない」なんて一言も書いてないぞ
繰り返すが「開発環境を一切書いてないから助言が出来るわけもなくあくまで一般的な方法で手っ取り早いのを伝えただけ。」だぞ

**デフォルトの名無しさん** · 2024/10/30(水) 20:01:18.39

>>292
そもそもphpでもjavaでもまたひと手間かよと思ったら泣きたくなってよー
とらいえずExcelでのデータベースはできたんだ
ただ数万の画像表示でクッソ重いからファイルパスに変えたけど
でも画像べらーって表示したいじゃん
これを試しに画像だけでもHTMLでやったらどうなるかと思ったら数万枚数十万のサムネ画像べらーっとはったら重いわ
そうなんだよな、htmlしばりするわけじゃねーもんな
とりあえず、EXCELでデータベース作って、SQliteにぶち込んでそれで様子みてる
そっから先は何でどうするか選択肢がおおすぎてわけわからなくなってんだわ
マツリポストは後生やからさぁ、いまのところかんべんしてつかーさい

**デフォルトの名無しさん** · 2024/10/30(水) 20:04:46.88

マルチポストとかこんなところにそんなのが存在するのか？

**デフォルトの名無しさん** · 2024/10/30(水) 20:07:31.52

良く考えたら風俗嬢とかのサイトでも女の子すべてずらーっと見せるの無いよな
数十毎にくぎってページ１とか２にしてるわけだし

**デフォルトの名無しさん** · 2024/10/30(水) 21:20:15.49

ガイジ大暴れ

**デフォルトの名無しさん** · 2024/10/31(木) 13:02:50.98

馬鹿には無理

**デフォルトの名無しさん** · 2024/11/01(金) 00:10:42.00

>>291
そんな付加をかけまくるツール、人間が少しだけ見るためのツールに需要はない。

**デフォルトの名無しさん** · 2024/11/01(金) 09:10:10.59

>>298
色々なサイトでサムネを1ページの中に限定して表示してるのは数を無限や数万数十万にすると負荷がかかるからか
なるほどなあ

**デフォルトの名無しさん** · 2024/11/01(金) 19:58:15.69

つ<img loading="lazy">

てか結局何がしたいの？
explorer＋特大アイコンで駄目な理由は？

**デフォルトの名無しさん** · 2024/11/01(金) 19:58:32.10

twitterのフォロワー整理ツールとか参考になるわ

**デフォルトの名無しさん** · 2024/11/03(日) 17:55:14.49

>>300
画像がDBに入っていると、エクスプローラーでは見れないんだよね

**デフォルトの名無しさん** · 2024/11/03(日) 18:18:24.25

>>302
それはそうだが、そもそも画像をDBに入れる意味がない
ただ初心者あるあるらしく、「(画像掲示板では)そうじゃなくてファイル名だけDBに入れてapacheに直接配信させるんだ」と
説明してたサイトがあったがすぐには出てこない

なおSQLiteはBLOBにもインデックス張れるらしいが、そんな使い方しないだろ

**デフォルトの名無しさん** · 2024/11/03(日) 18:54:12.64

>>303
上級者でもあるあるだけどね
デメリット大きいけどDBに入れたら入れたで便利なことも多いんだよね
もっと良かったこと探しをしろ

**デフォルトの名無しさん** · 2024/11/03(日) 20:08:56.01

ないと思うが、まあ上級者なら自分で何とかしろ
なお293なら画像をDBに入れてなければ解決してる

**デフォルトの名無しさん** · 2024/11/03(日) 22:39:10.72

何も解決してないだろｗｗ

**デフォルトの名無しさん** · 2024/11/04(月) 14:37:07.62

ずっとBAD GATEWAY

**デフォルトの名無しさん** · 2024/11/04(月) 14:37:49.34

っつーのは書けるのか　なんてこった

解決しなきゃいけない案件じゃねーだろ　画面いっぱいに数万もの大量な画像をずらーっと表示したいなんて要望は
そも、それをしてからその先どうしたいんだ？　それを一向に書こうとしない相談者に難がある
表示したらそれで満足なんか？
ランダムに表示するようにでもしなきゃ、毎回その数万の画像のうち特定の一部だけを目撃することに成る　それに意味は？
小アイコンサイズで画面いっぱいに貼ったとしてFHDモニタで250枚程度だ　もっとちっさくした画像でも貼ろうってのか
いろんな画像が次々湧いてくるようなエフェクト掛けて、とかならDBだのSQLだのほぼほぼ関係ねーわ

**デフォルトの名無しさん** · 2024/11/04(月) 14:52:26.31

>>308
何も解決していないのに「なお293なら画像をDBに入れてなければ解決してる(ｷﾘｯ)」みたいな痛いレスが面白かっただけだよ

**デフォルトの名無しさん** · 2024/11/06(水) 08:23:55.64

>>299
RDBでデータ型が画像データというデータ型は聞いたことがない。

RDBは画像データのバイナリデータか、画像データファイル形式に近いラージオブジェクト型。
単に画像データファイルへのリンクが入っているだけという設計もある。

**デフォルトの名無しさん** · 2024/11/06(水) 08:54:43.24

INNER JOINとEXISTSどっちがいいんだ？

**デフォルトの名無しさん** · 2024/11/06(水) 10:46:12.80

使い途がちがう　EXISTSはture/falseを返すだけ

**デフォルトの名無しさん** · 2024/11/06(水) 11:02:31.90

INNER JOINでもWHERE EXISTSでも、テーブルBのデータを使ってテーブルAのデータを絞り込んでSELECTするができるじゃん
性能的にどっちがいいんだっていう

**デフォルトの名無しさん** · 2024/11/06(水) 12:00:06.03

>>313
そもそも実行計画・実行プランくらいは見ろよ
書き方がどうとかいい加減にしろ！

**デフォルトの名無しさん** · 2024/11/06(水) 12:02:25.42

>>313
対象レコードの存在有無を判定するのに内部結合をするのは意図がわからないのでやめなさい。

しかも処理コストが高くなるのが普通だ。

**313** · 2024/11/07(木) 08:53:30.88

>>314-315
はい、ごめんなさい……

**デフォルトの名無しさん** · 2024/11/12(火) 08:43:58.73

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の方が実行順が先なのになぜですか？

警備員[Lv.1][新芽] · 2024/11/12(火) 09:07:16.39

抽出条件で行の絞り込みをするのは、SELECTでなく WHEREかと
行を絞ってからグループ化するのはそうかもしれないけど、
統一感はあった方がいいとは思いますね

**デフォルトの名無しさん** · 2024/11/12(火) 11:00:57.73

>>317
GROUP BYでもcolumn aliasが使えるようPostgresが拡張してるから
集約関数とかを両方に書かないといけないの面倒でしょ？

**317** · 2024/11/12(火) 12:30:43.18

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**317** · 2024/11/12(火) 12:30:43.35

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**317** · 2024/11/12(火) 12:30:44.59

>> 319
Postgresさんが気を利かせてくれてるわけですね？
ありがとうございます。

**デフォルトの名無しさん** · 2024/11/12(火) 12:31:48.29

すみません。ブラウザの反応がなかったので何回も書込み押してしまいました

**デフォルトの名無しさん** · 2024/11/12(火) 15:44:40.37

view造って先にaaaのみにするんじゃね

警備員[Lv.4][新芽] · 2024/11/12(火) 16:45:36.43

WHEREによるフィルタが先で、SELECTによるマップがあとなのかな

**デフォルトの名無しさん** · 2024/11/12(火) 17:29:22.04

>>322
そんなに列別名を使いたい理由がわからない。

集合演算のSELECTでテーブルによって列名が異なるならやらないといけないが、そういうSELECTでないのにテーブル別名メリットが大きいが、列別名を使うメリットなんてほとんどないよ。

**デフォルトの名無しさん** · 2024/11/12(火) 17:31:02.65

>>325
SQLの構文解析エンジンの仕様によるような書き方をするのがそもそもの間違いだよね。

警備員[Lv.6][新芽] · 2024/11/12(火) 18:00:22.86

>>327
ですね

警備員[Lv.6][新芽] · 2024/11/12(火) 18:13:14.69

LINQを最初に見たとき、なんでこんな順序なんだ? と思ったけど、自然な順序なのかもね
FROM→WHERE→SELECT

しばらくLINQやってないから、うろ覚えで見当違いだったらごめんなさい

**デフォルトの名無しさん** · 2024/11/12(火) 19:58:46.82

>>329
SQLは自然言語に近い表現で作られた
英語の語順になっているから、日本人には変な順番に見えるだけ

**デフォルトの名無しさん** · 2024/12/20(金) 16:41:43.73

テーブルごと全てのカラムにまとめて別名付けるとかできないのかな
以下のような場合に別名付けるとき
テーブル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_*
みたいに書けたら便利なのに

**デフォルトの名無しさん** · 2024/12/21(土) 11:36:41.92

うちはそのまま A.name のまま扱ってるよ

**デフォルトの名無しさん** · 2024/12/21(土) 19:55:23.41

>>331
またそのネタかよw

**デフォルトの名無しさん** · 2024/12/21(土) 20:43:39.23

SQLを出力するプログラム位かけるやろ

**313** · 2024/12/23(月) 08:20:37.09

>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ

**デフォルトの名無しさん** · 2024/12/23(月) 10:17:08.30

>>333
また、って言うくらいには結構求められている機能だと思う

**デフォルトの名無しさん** · 2024/12/23(月) 18:35:45.31

>>329
LINQはそもそも.NETのコードの物だから
メソッドチェーンで書く時の順番がそのままになってるだけよ

HogeList.Where().Select()って書き方になるからクエリ式もそうなる。

**デフォルトの名無しさん** · 2024/12/24(火) 09:46:38.33

>>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
とシンプルに書けて良いよ

**デフォルトの名無しさん** · 2024/12/24(火) 12:30:30.62

>338
>331を読むに、別名（エイリアス）でテーブル名付けたいって事でしょ
確かに長ったらしいテーブル名は一括で一文字のエイリアス名を付けたいな…の思う事もあるから>338の言わんとしてることも分かる

**デフォルトの名無しさん** · 2024/12/24(火) 22:39:03.73

>>335
標示SQLではSELECTよりもWITHが先

**デフォルトの名無しさん** · 2024/12/24(火) 22:40:09.34

>>338
同じカラム名なのに意味が異なるという狂った設計なのが間違い

**デフォルトの名無しさん** · 2024/12/25(水) 01:30:11.46

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”でアクセスするんだから表示調整くらい簡単にできそうだけどな

**デフォルトの名無しさん** · 2024/12/25(水) 08:15:20.48

誰もWITHの話なんかしとらんのに突然の主張ｗ

**デフォルトの名無しさん** · 2024/12/25(水) 12:26:11.92

日本語SQLスズラン

**デフォルトの名無しさん** · 2024/12/25(水) 15:26:23.80

be with you

**デフォルトの名無しさん** · 2024/12/25(水) 17:53:18.64

>>343
SELECT句よりも先にWITH句を書くので、SELECT句が先ではない。

**デフォルトの名無しさん** · 2024/12/25(水) 17:56:53.42

>>342
根本的に同じカラム名なのに別のカラムという設計がおかしい

どちらかのテーブルにしかないカラムなら、修飾そのものがいらない

それはあんたはSQLの話ではなくて、別の製品の仕様の話をしている

それに同じ名前のカラム名なら別名を定義するべきだ

**デフォルトの名無しさん** · 2024/12/25(水) 17:58:44.64

　
SQLを適当に書く人間が増えて、めちゃくちゃなシステムだらけになった。

同じカラムが、同じカラムがというなら、結合したビューでも用意しとけよw

**デフォルトの名無しさん** · 2024/12/25(水) 18:33:32.24

元の話も読めないようなヤツはWITHがどうのと主張しとらんと黙っといた方がいいよｗ

**デフォルトの名無しさん** · 2024/12/25(水) 18:36:08.08

>>346
誰もWITHの話なんかしとらんのに突然の主張ｗ

**デフォルトの名無しさん** · 2024/12/25(水) 19:42:44.67

>>350
335 313 sage 2024/12/23(月) 08:20:37.09 ID:hrYrd+aN
>>330
クエリ式であってSQLじゃねぇだろ
SQLの語順ならSELECTが最初だ

**デフォルトの名無しさん** · 2024/12/25(水) 19:44:16.65

>>349
SQLの構文仕様を調べたことがあるのか？

SQLそのものは自然言語の英語の語順になっているだけ

**デフォルトの名無しさん** · 2024/12/25(水) 19:47:55.88

「クエリ式」はSQLの世界の話ではなく、SQLを組み立てる側のライブラリの世界の話。

使われる方が使う方を意識するという発想で設計書を書かせようとする人間がいるが、それだと延々とドキュメントを修正することになる。

世界中の人間に聞いて回ってドキュメントを修正するなど無理だし、無意味。

**デフォルトの名無しさん** · 2024/12/25(水) 21:03:35.85

ダメだわこの頭でっかちｗ

**デフォルトの名無しさん** · 2024/12/26(木) 13:44:41.34

>>341
うれしい副産物として、違うカラム名にできるというメリットもある

**デフォルトの名無しさん** · 2024/12/30(月) 02:42:59.39

>>354
SQLを書きたくないという理由を聞きたい
他人にぶん投げられれば気が済むのか？

**デフォルトの名無しさん** · 2024/12/30(月) 02:44:55.46

なぜ「データベース」板を無視して「プログラム」板に書いているのも謎

**デフォルトの名無しさん** · 2024/12/30(月) 14:22:49.66

SQLなんて一回描いたら何度も描き治すもんでもないからな
面倒臭がるのは怠慢

**デフォルトの名無しさん** · 2024/12/30(月) 19:29:38.65

>>358
なおすでーー

**デフォルトの名無しさん** · 2025/01/01(水) 21:42:25.49

>>359
そう何度も直すことは無いよ

**デフォルトの名無しさん** · 2025/01/01(水) 23:12:26.15

へぼかったら治すでーー

**デフォルトの名無しさん** · 2025/01/05(日) 10:38:54.01

単にテキストエディタの機能を使いこなせずに毎度、すべてキー入力している初心者は案外、多い。

**デフォルトの名無しさん** · 2025/01/05(日) 10:48:34.28

ORMなんていらん

**デフォルトの名無しさん** · 2025/01/05(日) 19:51:54.27

サブクエリ難しい

**デフォルトの名無しさん** · 2025/01/05(日) 19:52:23.20

息をするようにSQLを書きたい

**デフォルトの名無しさん** · 2025/01/05(日) 20:49:47.84

>>364
当該処理がクエリを2回以上発行することを許されてる仕様や環境なら、無理にサブクエリ１発で処理しようとせず2回以上に分けて処理するのも手だよ
サブクエリって見づらいしメンテナンスしづらいし

**デフォルトの名無しさん** · 2025/01/05(日) 22:36:32.88

CTEのおかげてサブクエリの出番はめっきり少なくなったよね

**デフォルトの名無しさん** · 2025/01/06(月) 12:33:31.51

>>367
ＣＴＥってなに？

**デフォルトの名無しさん** · 2025/01/06(月) 18:37:10.53

>>366

ありがとう
やってみる
逆にそれでサブクエリの感覚が掴めるかもしれないと勝手な期待をしている
accessとExcelVBAでやっているけど、IT素人のPC好きなおじさんがやる
やってるから何分感覚がつかめない
ミックさんのデータベース入門は読んでいるけど読み切れていない

**デフォルトの名無しさん** · 2025/01/06(月) 20:05:07.43

>>369
そうそう、その視点や観点が本当に大事
プログラム全般そうだけど一気に書こうとするとスパゲティ化して自分でも訳わからなくなるから
必ず最小から始めて、それらをくっ付けて大きくしていくみたいな感覚が大事

**デフォルトの名無しさん** · 2025/01/09(木) 00:01:55.02

サブクエリは普通に使うだろ

**デフォルトの名無しさん** · 2025/01/11(土) 10:22:19.58

サブクエリを使うクエリを分解したらたいていN+1になるしな

**デフォルトの名無しさん** · 2025/01/19(日) 01:50:01.24

サブクエリ使う理由ってめんどくさがったり一時領域をケチる以外に理由ないよ
サブクエリを使わずに結果を出すようにした方がメンテもパフォーマンスも上がる

**デフォルトの名無しさん** · 2025/01/19(日) 02:17:21.82

サブクエリの有無ごときで議論になるの笑ってしまうなw
どんなちっこいアプリなんだ？電卓とか？

**デフォルトの名無しさん** · 2025/01/19(日) 06:33:56.88

1週間も経って突然貶し始める方が笑ってしまうわ

**デフォルトの名無しさん** · 2025/01/19(日) 09:51:50.41

どこの句のどういう使い方をするサブクエリなのか書いてくれないと、サブクエリを使うべきなのか、そうでないか答えようがない。

警備員[Lv.1][新芽] · 2025/01/19(日) 13:34:54.51

SQLを複数回に分割して発行すると、その間DBに更新がないことを担保する必要がありますか？

**デフォルトの名無しさん** · 2025/01/19(日) 16:06:56.18

トランザクションを指定すれば？

**デフォルトの名無しさん** · 2025/01/19(日) 16:20:11.02

そこはSQLを複数回に分割して発行するかどうかよりも上位のレベルで
トランザクションや同時実行制御の観点から設計しておくべき事項
担保する必要性の有無は分割しようがしまいが変わらない

警備員[Lv.4][新芽] · 2025/01/19(日) 18:28:02.90

やはりトランザクションですね
ありがとうございます!!

警備員[Lv.4][新芽] · 2025/01/19(日) 18:29:15.30

ちなみに、サブクエリとするか分割するかのレスに乗っかって、でした

**デフォルトの名無しさん** · 2025/01/20(月) 11:39:20.74

サブクエリを使わないで、一旦チンポテーブルに書き出す方式があったよね
あれなんだっけか

警備員[Lv.1][新芽] · 2025/01/20(月) 18:23:14.14

次の3つのフィールドで構成される複合主キーがあり
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？

**デフォルトの名無しさん** · 2025/01/20(月) 18:55:00.26

キーのバラつき具合やオプティマイザの機能にもよるから一概に不要とも作成すべきとも言えない

**デフォルトの名無しさん** · 2025/01/20(月) 18:55:26.16

実際のクエリプランを見て判断

警備員[Lv.3][新芽] · 2025/01/20(月) 19:12:32.30

ありがとうございます>>383です
ちなみにaccessです

警備員[Lv.3][新芽] · 2025/01/20(月) 19:14:05.86

>>3々3です
accessで複合主キーを設定したとき、インデックスは自動で付与されるでしょうか

**デフォルトの名無しさん** · 2025/01/21(火) 08:53:02.94

インデックスじゃない主キーってなんだ……。

警備員[Lv.5][新芽] · 2025/01/21(火) 09:13:36.90

>>388
調べてみるとそうみたいなんだけど(主キーにはインデックスが張られる)、単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
それがどういうことか(インデックスが張られているか)分からなくて
分かりにくくてごめんね

**デフォルトの名無しさん** · 2025/01/21(火) 11:15:04.33

>>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があるのかもしれんが俺は知らん

**デフォルトの名無しさん** · 2025/01/21(火) 11:23:25.76

>>389
> 単一主キーだと、該当キーにRequired、Uniqueなインデックスが作成されるけど、複合主キーでは個々のフィールドに個別にはインデックスが作成されてなくて
これは少し勘違いしてる
インデックスはあくまでB木であって、個々のフィールドやカラムとは全く別物
インデックスが当たってるかは、クエリプランで確認すべき事

警備員[Lv.7][新芽] · 2025/01/21(火) 13:20:25.85

>>389です
ありがとうございます

(以下Accessです)
新たにテーブルに、主キー(PK1,PK2,PK3)を作成した段階で数万件のレコードを入れ、仮に(PK1,PK3)をキーとしてSELECTで抽出をするとめちゃくちゃ遅い…(1)
上のテーブルの主キーの個々のフィールド(3つ)にインデックスを設定して(1)と同じ条件の抽出をするとかなり速い…(2)
(2)のインデックスを削除して主キーと同じフィールドに複合インデックスを設定するともっと速い…(3)

(1):(2):(3)=65:1.5:1
くらいの比率でした

主キーを設定しただけではとても遅かったです(65倍)

なにか設定・前提に誤りがあるかもしれません

警備員[Lv.7][新芽] · 2025/01/21(火) 13:21:48.40

実行計画の出し方は調べてみます
多分見方が分かりませんがw

**デフォルトの名無しさん** · 2025/01/21(火) 16:54:19.10

>>392
(1)で設定した複合主キーと
(3)で設定した複合インデックスとで
インデックスを構成するカラムの順番は本当に同じ？

警備員[Lv.8][新芽] · 2025/01/21(火) 17:55:49.71

>>394
すみません、ちょっと投稿内容に誤りがありました

(1)の複合主キーと、(3)の複合インデックスをまったく同じフィールド、個数、順序とすると、(1)と同じように、複合主キーのみでインデックスを設定しないときの同じように65倍の時間が掛かりました
デフォルトで設定されたインデックスと一致しているので当然なのかもしれません

先ほどの(3)の結果としてを得たのは、試行錯誤して複合インデックスから検索キーとしないフィールドを削除したもので、複合主キーのフィールド数より2つ少ないです
後出しになりすみません

データの内容によっても結果は変わるでしょうし、オレ環なので諦めるしかないかなと

警備員[Lv.8][新芽] · 2025/01/21(火) 18:09:31.85

簡単のため、当初複合主キーのフィールド数を3としました

**デフォルトの名無しさん** · 2025/01/22(水) 00:08:11.72

{PK1,PK2,PK3}で複合キーが定義されてる場合
検索条件が{PK1}か{PK1, PK2}か{PK1, PK2, PK3}であればどのDBMSでも大半のケースでインデックスが使われる
検索条件が{PK1, PK3}の場合はPK1のselectivity次第でインデックスが使われるものがある
検索条件が{PK2, PK3}のように一番左のカラムが含まれない場合はindex skip scanという機能が実装されてなければインデックスは使われない(Accessにはたぶん実装されてない)

他のクエリとの兼ね合いで複合主キーを構成するカラムの順序を変更できないということであれば該当クエリ用に複合インデックスを追加するのは妥当

**デフォルトの名無しさん** · 2025/01/22(水) 00:28:31.31

>>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;
でαとβはほぼ同速になるはずだよ

警備員[Lv.3][新芽] · 2025/01/22(水) 01:45:12.43

>>390
>>397
ありがとうございます
最左のカラムを検索キーとするかがポイントなんですね

当初は>>390での指摘がピンときていませんでした
合間のレスで「仮に(PK1,PK3)で検索し」は迂闊でした
いまは手元に試験用のコードがありませんが、最左のカラムを含んでいなかったと思います

SQLをずいぶん自由に書けるようになったと思っていましたが、テーブル、インデックスの作成がこんなに大切だったと知りました…

**デフォルトの名無しさん** · 2025/01/22(水) 01:53:19.83

そもそもＡＣＣＥＳＳのクエリプラントとか、取得大変だがな

**デフォルトの名無しさん** · 2025/01/22(水) 05:04:07.48

ACCESSにクエリプランなんてあるん？ｗ

ファイルで配布できる必要があるとかじゃなければ、MS SQL Expressなり使った方がやりやすくない？
昔と違ってGUIツールも今は無料配布になってるし。

**デフォルトの名無しさん** · 2025/01/22(水) 07:08:36.05

>>399
> 最左のカラムを検索キーとするかがポイントなんですね
違う。というか理由を理解ではなく結果を暗記しようとする辺り、文系馬鹿の匂いがするが、
とにかく、「B木」でググって記事を読め
現在のプログラミングでは基本で、そこそこ初心者が記事を書くネタになってるから、いくらでも出てくる
そしてVBAにもハッシュはあるだろ。ググるとScripting.Dictionaryと出てくるが、中身は同様にB木のはずだから、
何か知らんが速いという事で済まさず、この機会にちゃんと理解しろ

そしてその言い方なら、
左側が全部揃ってるかがポイント
が正解になる

ただ、遅くて困るのならインデックス張ればいいだけではあるが

警備員[Lv.5][新芽] · 2025/01/22(水) 09:37:01.44

>>402
ありがとうございます
B木の「B」はBinaryでなくBalanceだったのですね
B木の深さは複合キーの個数で一定となるツリーなんですね
二分木をイメージして「??」でしたが、B木の構造がイメージできればインデックスの効果が得られるか否かが分かりやすいと思いました

**デフォルトの名無しさん** · 2025/01/22(水) 10:44:07.12

>>403
> 二分木をイメージして「??」でしたが
いやそういう問題じゃない
というか相変わらずインデックスが何かさっぱり分かってないようだが、単なるリーフへの探索手段だぞ

実際はこんなキーの分け方はあり得ないが、馬鹿でも分かるように敢えて例とすると、
お前が名詞を1,000枚持ってて、あいうえお順に格納して保管してるとする
これは主キーが複合キーの{PK1:苗字1文字目, PK2:苗字2文字目以降, PK3:名前}として、
石破茂を{'石','破','茂'},
岸田文雄を{'岸','田','文雄'}
と格納されてる状態と見なせる
これに対して、{PK2,PK3}の検索、例えば{'田',’茂'}では全く使い物にならないのは分かるだろ。これがインデックスが機能してない状況
同様に、{PK1,PK3}の{'吉','茂'}も無理ゲーと分かるだろ。これもインデックスが機能してない状況
逆に、{PK1,PK2}の検索、{'鈴','木'}なら範囲を確定させられるだろ。これがインデックスが機能してる状況

というか言っちゃ悪いがVBA+accessってプログラマではなくExcel職人上がりも多いのでこの空回りなのだと思うが、
実際、Excel職人ならこの辺理解せずすっ飛ばして「遅いからインデックス張る」で済ませていい
プログラマなら、ちゃんと理解しろ。「赤黒木」とかもお前には有用だろうよ

警備員[Lv.7][新芽] · 2025/01/22(水) 10:58:55.44

B木については知らなかったが、今回の複合インデックスの件について二分木は論外だとは分かっています

ちなみに、>>402ハッシュの中身がB木というのは自分の認識と異なります

字面でうまく伝わらない部分はあったと思いますが、B木を知ることができ(あえて理解とは言わない)よかったです
ありがとうございました

**デフォルトの名無しさん** · 2025/01/22(水) 11:07:43.80

中途半端な知識で間違ったことばっかり書いてるのに
人を馬鹿する自称バカではない理系おじさんは少し自重したほうがいい

警備員[Lv.7][新芽] · 2025/01/22(水) 11:27:02.25

>>405
x ハッシュの中身が
o Scripting.Dictionaryの中身が
文脈から分かったかもしれませんが

**デフォルトの名無しさん** · 2025/01/22(水) 11:27:27.98

>>405
> 今回の複合インデックスの件について二分木は論外だとは分かっています
いやそうじゃねえ
そもそも論外でもないし、インデックスが二分木でも問題ないし、この場合には二分木もB木の一種だよ
B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし

まあ君に理解する気がないのは分かったし、実際に理解しなくても済む人達も大勢居るのも事実
ただプログラマならどのみちいつか引っかかるから、この機会にちゃんと理解しといた方が得だぞという話
君がどうするかは君が決める事

**デフォルトの名無しさん** · 2025/01/22(水) 11:42:36.84

>B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
君が論外

**デフォルトの名無しさん** · 2025/01/22(水) 12:42:33.57

>>407,409
そうじゃない、というかそこは問題ではない

というのが分からないのが問題なのだろうが、君は全てを「具象」で捉えて「暗記」してるだけだろ、これは典型的な文系のやり方
本来は「抽象」で捉えて「理解」しないといけない項目
「B木」も「二分木」も(昔ながらのハッシュ関数を使った)「ハッシュ」も別物ではなくて、
同一の物を分類してるだけ、しかも直交もしてない

話を戻すと、問題は、
・DBのインデックス動作が分からない
・どうインデックスが作成されるかも分からないし、
・どういうクエリならインデックスが使われるのかも分からない
なんだろ

正攻法：（＝プログラマ向け)
・インデックスの実装の仕方(の一つ)を理解する
　これにより、インデックスに何が必要か、インデックスで何が出来、何が出来ないかを直感的に判断出来るようになる
　(実際の実装では高速化の為にあれこれやってるだろうが、これは今回の目的に対しては全くどうでもいい事)

迂回策：
・クエリプランで毎回確認する
　とはいえ読めるのかあれ？
　あれを読む努力をするくらいなら、上記のインデックスを理解する努力の方が実になるはず
　その上で、このDBではどうなのか？の判断の為に使うものだろあれは

迂回策次善案：（＝Excel職人向け)
・クエリが遅い場合はインデックスを作るようにする

だと思うよ
まあ実際Excel職人っぽいしどうぞお好きにだが、
でも今回理解しておかないと次回以降も同じ所で引っかかり続けるだけだから、
それが嫌なら数時間～数日かけてでもこの機会に理解するしかないでしょ

**デフォルトの名無しさん** · 2025/01/22(水) 12:49:28.79

>>410訂正
× 同一の物
○ 同種の物
無駄に絡まれそうなので念のため

まあ俺がどう論外である事を証明したところで、
君がインデックスを理解する事には繋がらないよ
君は努力の方向を間違ってる
(ネットにはこのタイプも多いけども)

**デフォルトの名無しさん** · 2025/01/22(水) 13:23:48.02

どんなにアスペな言い訳しようが君がバカだという事実に変わりはないよ

警備員[Lv.8][新芽] · 2025/01/22(水) 13:46:46.67

>>405です

途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました

理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました

**デフォルトの名無しさん** · 2025/01/22(水) 18:46:15.47

>>413
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄

> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)

とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき

例えばさ、>>383に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ

**デフォルトの名無しさん** · 2025/01/22(水) 21:30:12.00

おっさん、文章が長いな。もっと簡潔に書きなさい。あなたの文章にインデックス貼ってクエリもチューニングした方が良いぞ

**デフォルトの名無しさん** · 2025/01/22(水) 23:15:16.32

絵に書いたような老害だなｗ

**デフォルトの名無しさん** · 2025/01/22(水) 23:17:45.52

ありゃ「描いた」だぞと老害に指摘されそうだなｗ

**デフォルトの名無しさん** · 2025/01/22(水) 23:29:43.66

老害でも技術力があれば匿名掲示板では役立つけどどう見てもないから救いようがない

絶対干されてるタイプ

**デフォルトの名無しさん** · 2025/01/23(木) 19:03:57.14

どうでもいいけど、制約とインデックスを同一として扱ってるのがモヤるわ
ユニーク制約と主キー制約をインデックスで処理しないＤＢＭＳはみたことないとしても

**デフォルトの名無しさん** · 2025/01/23(木) 19:56:56.31

お前の方が色々混同してそうだが

警備員[Lv.1][新芽] · 2025/01/23(木) 23:23:26.10

さ…さすが～!
し…知らなかった～!
す…すごーい!
せ…センスい～ぃ!
そ…そうなんだ～!
(「合コンさしすせそ」より)

**デフォルトの名無しさん** · 2025/01/23(木) 23:29:29.44

制約の話で思い出したがAccessの場合は
foreign key制約を設定すればインデックスが自動で出来たはず

(PK1, PK2, PK3)で構成される複合主キーがあって
検索キーとして(PK2, PK3)を利用したいということなら
PK1と(PK2, PK3)は違う親テーブルから主キーを引き継いでるんだろうから
そこにインデックスを張らないという選択はほぼ無いな

**デフォルトの名無しさん** · 2025/01/24(金) 04:28:21.32

383以降を見る限り、そんな高級な話ではなく、まるっきり分かってなかっただけだろ
そして(PK2,PK3,PK1)と出来なかった理由の推定なら、そこは(PK1,PK2)とPK3とくくるべき

**デフォルトの名無しさん** · 2025/01/24(金) 11:19:27.52

分かってないのになぜ無理して絡もうとするのが

**デフォルトの名無しさん** · 2025/02/03(月) 18:36:54.12

PostgreSQLを使っているのですが、

更新前のデータも参照したいので、
更新処理を、元のデータに変更を加えたデータを追記し、更新元のデータに最新ではないフラグを付ける形でやっています。

新しくカラムを追加したのですが、更新処理の変更を忘れて、更新すると新しいカラムがデフォルト値に戻されてしまうバグを作ってしまいました。

既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？

**デフォルトの名無しさん** · 2025/02/03(月) 23:14:40.68

>>425
>既存の行をコピーして、primary keyと変更したいカラムだけ変更する方法ってありませんか？
この質問はバグにより作成されたデータの復旧作業方法として質問してる？
それとも一般的にそういう方法ないかということ？
あるいはカラム追加やカラム名の変更があっても更新処理のSQLを修正しなくてもいいようにする方法を聞いてる？

>更新前のデータも参照したいので、
ここで言いってる”参照”は外部キーとして他のテーブルから参照するという意味？
それとも単に更新履歴が閲覧できればいいという意味？

**デフォルトの名無しさん** · 2025/02/06(木) 00:29:05.51

>>425
あるよ
selectしたものを使ってupdateすればいい

**デフォルトの名無しさん** · 2025/02/07(金) 21:07:33.75

>>425
トリガーというものがあります

**デフォルトの名無しさん** · 2025/02/07(金) 21:08:11.88

>>425
https://www.postgresql.jp/docs/9.4/sql-createtrigger.html

**デフォルトの名無しさん** · 2025/02/07(金) 22:21:05.36

むしろトリガーの変更を忘れてバグったんじゃないの？

**デフォルトの名無しさん** · 2025/02/07(金) 23:13:03.59

> PostgreSQLでは、トリガ動作として、ユーザ定義関数の実行しか認めていません。
> 標準では、多数の他のSQLコマンドを実行させることができます。
> 例えば、トリガ動作としてCREATE TABLEを実行させることも可能です。
> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。
糞仕様杉ワロタ

**デフォルトの名無しさん** · 2025/02/08(土) 11:50:00.86

> この制限を回避する方法は簡単です。必要なコマンドを実行するユーザ定義関数を作成すればよいのです。

この方針は正しいと思うけどな
こういうセキュリティに敏感な場所は出入口を一ヶ所に絞るのは基本だよ

**デフォルトの名無しさん** · 2025/02/08(土) 12:46:18.46

いや色々おかしいよお前、多分DB板出身だろうから帰れ
逆に質問者もDB屋ならDB板の方が合ってるとも思うが

**デフォルトの名無しさん** · 2025/02/08(土) 13:11:35.92

正しいわけないだろｗ

Postgresの仕組み的に関数化が必要なら内部的にラップしとけばいいだけ
実行権限をトリガに対して設定できないとか非標準を維持し続けるほど大した意味はない

**デフォルトの名無しさん** · 2025/02/09(日) 03:19:16.45

ここの人らはNoSQLはどういう扱いなの

**デフォルトの名無しさん** · 2025/02/09(日) 12:18:58.85

俺個人としては同じDB枠の扱い
プライマリキーやインデックス等、DBとしての使い方は同じで、
それを設定する言語が、SQLか、或いは一般プログラミング言語か、という程度だから

だからこのスレも俺には「DBなら俺に訊け」でもいいんだが、このスレはテンプレないんだな
俺が主流派かどうかは分からない
SQLじゃないとヤダ、って奴が多ければスレを分けるべきだろうが、
正直分けるほど人いないし、NoSQLもここで聞いていいのでは？答える奴が居るかは知らんが

ただ、383も425も、SQLではなく、DBを分かってないから話がおかしくなってるので、
実質SQLではなくDBの質問になってるし、NoSQLでも結果的に同じだと思うよ

個別DBに特化した話等なら、DB板に行った方がいい
ただ、DB板の連中はプログラミングをしない/出来ないようなので、
432のように、プログラマから見たら明らかにトンチンカンな回答が返ってくる
それでもDB固有の問題には詳しいだろうよ

**デフォルトの名無しさん** · 2025/02/09(日) 18:18:30.19

>>431
トリガーそのものにロジックは必要ないとしてトリガーを仕様に取り込んだせいでそうなっただけ

**デフォルトの名無しさん** · 2025/02/09(日) 18:19:47.93

>>434
Oracle以外はあとからOracleDBに追従したから、元のクソ仕様のせいで制限がたくさんある。

**デフォルトの名無しさん** · 2025/02/09(日) 18:31:02.14

出た！
DB板の荒らし
通称ボラクル君w

**デフォルトの名無しさん** · 2025/02/09(日) 22:11:42.79

>>436
おまえ>>383のやり取りで嘘ばっか書いてたやつじゃん
反省したのか？