SQLなら俺に訊け [無断転載禁止]©2ch.net (457ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
398: デフォルトの名無しさん [sage] 2025/01/22(水) 00:28:31.31 ID:VcBzYOin(1/7) AAS
>>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;
でαとβはほぼ同速になるはずだよ
402(2): デフォルトの名無しさん [sage] 2025/01/22(水) 07:08:36.05 ID:VcBzYOin(2/7) AAS
>>399399(1): 警備員[Lv.3][新芽] [sage] 2025/01/22(水) 01:45:12.43 ID:x9n06qn/(1/2) AAS
>>390
>>397
ありがとうございます
最左のカラムを検索キーとするかがポイントなんですね
当初は>>390での指摘がピンときていませんでした
合間のレスで「仮に(PK1,PK3)で検索し」は迂闊でした
いまは手元に試験用のコードがありませんが、最左のカラムを含んでいなかったと思います
SQLをずいぶん自由に書けるようになったと思っていましたが、テーブル、インデックスの作成がこんなに大切だったと知りました…
> 最左のカラムを検索キーとするかがポイントなんですね
違う。というか理由を理解ではなく結果を暗記しようとする辺り、文系馬鹿の匂いがするが、
とにかく、「B木」でググって記事を読め
現在のプログラミングでは基本で、そこそこ初心者が記事を書くネタになってるから、いくらでも出てくる
そしてVBAにもハッシュはあるだろ。ググるとScripting.Dictionaryと出てくるが、中身は同様にB木のはずだから、
何か知らんが速いという事で済まさず、この機会にちゃんと理解しろ
そしてその言い方なら、
左側が全部揃ってるかがポイント
が正解になる
ただ、遅くて困るのならインデックス張ればいいだけではあるが
404: デフォルトの名無しさん [sage] 2025/01/22(水) 10:44:07.12 ID:VcBzYOin(3/7) AAS
>>403403(1): 警備員[Lv.5][新芽] [sage] 2025/01/22(水) 09:37:01.44 ID:x9n06qn/(2/2) AAS
>>402
ありがとうございます
B木の「B」はBinaryでなくBalanceだったのですね
B木の深さは複合キーの個数で一定となるツリーなんですね
二分木をイメージして「??」でしたが、B木の構造がイメージできればインデックスの効果が得られるか否かが分かりやすいと思いました
> 二分木をイメージして「??」でしたが
いやそういう問題じゃない
というか相変わらずインデックスが何かさっぱり分かってないようだが、単なるリーフへの探索手段だぞ
実際はこんなキーの分け方はあり得ないが、馬鹿でも分かるように敢えて例とすると、
お前が名詞を1,000枚持ってて、あいうえお順に格納して保管してるとする
これは主キーが複合キーの{PK1:苗字1文字目, PK2:苗字2文字目以降, PK3:名前}として、
石破茂を{'石','破','茂'},
岸田文雄を{'岸','田','文雄'}
と格納されてる状態と見なせる
これに対して、{PK2,PK3}の検索、例えば{'田',’茂'}では全く使い物にならないのは分かるだろ。これがインデックスが機能してない状況
同様に、{PK1,PK3}の{'吉','茂'}も無理ゲーと分かるだろ。これもインデックスが機能してない状況
逆に、{PK1,PK2}の検索、{'鈴','木'}なら範囲を確定させられるだろ。これがインデックスが機能してる状況
というか言っちゃ悪いがVBA+accessってプログラマではなくExcel職人上がりも多いのでこの空回りなのだと思うが、
実際、Excel職人ならこの辺理解せずすっ飛ばして「遅いからインデックス張る」で済ませていい
プログラマなら、ちゃんと理解しろ。「赤黒木」とかもお前には有用だろうよ
408: デフォルトの名無しさん [sage] 2025/01/22(水) 11:27:27.98 ID:VcBzYOin(4/7) AAS
>>405405(3): 警備員[Lv.7][新芽] [sage] 2025/01/22(水) 10:58:55.44 ID:ZVwqoD6m(1/3) AAS
B木については知らなかったが、今回の複合インデックスの件について二分木は論外だとは分かっています
ちなみに、>>402ハッシュの中身がB木というのは自分の認識と異なります
字面でうまく伝わらない部分はあったと思いますが、B木を知ることができ(あえて理解とは言わない)よかったです
ありがとうございました
> 今回の複合インデックスの件について二分木は論外だとは分かっています
いやそうじゃねえ
そもそも論外でもないし、インデックスが二分木でも問題ないし、この場合には二分木もB木の一種だよ
B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
まあ君に理解する気がないのは分かったし、実際に理解しなくても済む人達も大勢居るのも事実
ただプログラマならどのみちいつか引っかかるから、この機会にちゃんと理解しといた方が得だぞという話
君がどうするかは君が決める事
410(1): デフォルトの名無しさん [sage] 2025/01/22(水) 12:42:33.57 ID:VcBzYOin(5/7) AAS
>>407,409409(1): デフォルトの名無しさん [sage] 2025/01/22(水) 11:42:36.84 ID:a9tNcWhf(1) AAS
>B木とは深さ方向が一定になるように調節されてるものの呼称であり、実際は二分木が多数だろうし
君が論外
そうじゃない、というかそこは問題ではない
というのが分からないのが問題なのだろうが、君は全てを「具象」で捉えて「暗記」してるだけだろ、これは典型的な文系のやり方
本来は「抽象」で捉えて「理解」しないといけない項目
「B木」も「二分木」も(昔ながらのハッシュ関数を使った)「ハッシュ」も別物ではなくて、
同一の物を分類してるだけ、しかも直交もしてない
話を戻すと、問題は、
・DBのインデックス動作が分からない
・どうインデックスが作成されるかも分からないし、
・どういうクエリならインデックスが使われるのかも分からない
なんだろ
正攻法：（＝プログラマ向け)
・インデックスの実装の仕方(の一つ)を理解する
これにより、インデックスに何が必要か、インデックスで何が出来、何が出来ないかを直感的に判断出来るようになる
(実際の実装では高速化の為にあれこれやってるだろうが、これは今回の目的に対しては全くどうでもいい事)
迂回策：
・クエリプランで毎回確認する
とはいえ読めるのかあれ？
あれを読む努力をするくらいなら、上記のインデックスを理解する努力の方が実になるはず
その上で、このDBではどうなのか？の判断の為に使うものだろあれは
迂回策次善案：（＝Excel職人向け)
・クエリが遅い場合はインデックスを作るようにする
だと思うよ
まあ実際Excel職人っぽいしどうぞお好きにだが、
でも今回理解しておかないと次回以降も同じ所で引っかかり続けるだけだから、
それが嫌なら数時間～数日かけてでもこの機会に理解するしかないでしょ
411: デフォルトの名無しさん [sage] 2025/01/22(水) 12:49:28.79 ID:VcBzYOin(6/7) AAS
>>410訂正
× 同一の物
○ 同種の物
無駄に絡まれそうなので念のため
まあ俺がどう論外である事を証明したところで、
君がインデックスを理解する事には繋がらないよ
君は努力の方向を間違ってる
(ネットにはこのタイプも多いけども)
414: デフォルトの名無しさん [sage] 2025/01/22(水) 18:46:15.47 ID:VcBzYOin(7/7) AAS
>>413413(1): 警備員[Lv.8][新芽] [sage] 2025/01/22(水) 13:46:46.67 ID:ZVwqoD6m(3/3) AAS
>>405です
途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄
> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)
とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき
例えばさ、>>383383(3): 警備員[Lv.1][新芽] [sage] 2025/01/20(月) 18:23:14.14 ID:O4abJDGp(1/3) AAS
次の3つのフィールドで構成される複合主キーがあり
(PK1, PK2, PK3)
検索キーとしてPK2とPK3だけをよく用いるとき、主キー以外にもインデックス(PK2, PK3)を作成すべきですか？
に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.024s