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

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

さあ

警備員[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のやり取りで嘘ばっか書いてたやつじゃん
反省したのか？

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

ならお前が正しいと思うことを書けばよいだけでは？

**デフォルトの名無しさん** · 2025/02/10(月) 00:33:14.69

nosqlは独自に覚えなきゃいけないことが多すぎるうえに制約も多い
awsとazureで同じ設計が通じるわけでもないし

**デフォルトの名無しさん** · 2025/02/10(月) 11:53:19.06

KVSですね判ります

**デフォルトの名無しさん** · 2025/02/10(月) 12:41:14.64

ベンダー違っても中身は全部Redisという場合もあるし単純なセッション管理にKVSを使うとかならベンダー違っても基本的に同じ設計になるしユースケース次第でいろいろ

NoSQLって言うだけだとリレーショナルじゃないくらいの意味しかなくて広すぎるから細かい話は一括りにはできない

**デフォルトの名無しさん** · 2025/05/11(日) 23:41:50.22

ミックさんの達人SQLは名著だと思うんだけど、関係が体であるとしている点については、群ですらないというamazonレビューの指摘の方が正しいように思うんだよね。ただ自分は文系で群とかちゃんと勉強したことないのであまり自信はない。数学できる人教えて。

**デフォルトの名無しさん** · 2025/05/12(月) 19:12:28.13

>>445
集合は数学とは違うよ

**デフォルトの名無しさん** · 2025/05/13(火) 14:41:24.56

SQLで無限集合出来んかな

**デフォルトの名無しさん** · 2025/05/14(水) 00:52:49.17

なんで havingとwhereは使い分ける必要があるの？
全部whereで済むように仕様を直してほしい

**デフォルトの名無しさん** · 2025/05/14(水) 01:47:48.71

意味違うと思うぞ。whereだけじゃ足りないんじゃね

**デフォルトの名無しさん** · 2025/05/14(水) 01:55:11.10

評価対象が行とグループ
評価タイミングも違うとchatGPTが教えてくれた

**デフォルトの名無しさん** · 2025/05/14(水) 06:22:22.00

そんなこともAIに訊かなきゃわからないんかよｗ

**デフォルトの名無しさん** · 2025/05/14(水) 08:46:47.35

スレ主じゃないので
LLM勉強になるぞ

**デフォルトの名無しさん** · 2025/05/14(水) 11:40:16.61

グループ化と関係なくHAVINGを使っているんだろうなw

**デフォルトの名無しさん** · 2025/05/14(水) 11:41:17.83

>>452
AIチャットは間違いを指摘してくれない

**デフォルトの名無しさん** · 2025/05/14(水) 12:56:57.46

LLMの勉強する前に対人会話の勉強しよう？

**デフォルトの名無しさん** · 2025/05/14(水) 13:29:13.49

お前らもﾈﾗｰだからLLMと大差ないぞ
教科書レベルの話はLLMさんが正確さ

**デフォルトの名無しさん** · 2025/05/15(木) 09:52:35.44

結局、>>445ってどう？　素人考えでは、群の条件のうち、「任意の元に対する逆元が存在する（逆元も関係の元である必要がある）」を、関係および関係上の演算は満たさないようにも思うんだけど。