SQLなら俺に訊け [無断転載禁止]©2ch.net (457レス)
上下前次1-新
抽出解除 レス栞
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
413(1): 警備員[Lv.8][新芽] [sage] 2025/01/22(水) 13:46:46.67 ID:ZVwqoD6m(3/3) AAS
>>405です
途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
また、複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
理解不足は否めませんが、実用上問題がないレベルとなったので、これでよしとします
ありがとうございました
414: デフォルトの名無しさん [sage] 2025/01/22(水) 18:46:15.47 ID:VcBzYOin(7/7) AAS
>>413
> 複合主キーの最左から順に一連の(部分)フィールドで検索できない場合は、別途インデックスを設定することで効果が得られることを確認しました
当たり前、というかDBの使い方の初段階で説明/理解すべき事柄
> 途中、どうも複合主キーの検索が遅く、複合主キーかフィールドを2つ削除して
> と書きましたが、少し理解するうちに、フィールドを削除せずとも順序を入れ替えることで高速化したこと
そうじゃない
ひととおり設計を理解した上で弄くり回して理解を深めるのなら身に付くが、
今の君のように、何も理解してない状態で試行錯誤したところで時間の無駄でしかないよ
(それよりは記事を漁って理解するまで何度も読み込む努力をした方が何倍もいい)
とはいえ、現実問題としてaccessの実アプリの方が優先なのは分かる
半年に一度くらいしかSQLも書かないのなら今の状態もありだ
ただ、毎日SQLを書いてる状況なら、どのみちいつか理解しなければ不便で仕方ないだけなので、
出来るだけ早いうちに理解を深めておくべき
例えばさ、>>383に戻ると、(この事を言ってるのかもしれんが)
複合主キーを(PK1, PK2, PK3)ではなく、
(PK2, PK3, PK1)としてテーブルを作成しておけば、今回のインデックスを別に作成する必要はなかったろ
だからテーブル作成時の時点で、将来どういうクエリが発行され、インデックスがどう適用されるかも設計されてるし、
逆に今の君のような状態では、適切なテーブル設計は出来ないんだよ
というか、
> 検索キーとしてPK2とPK3だけをよく用いるとき
の場合はむしろ(PK2, PK3, PK1)とするのが普通で、
つまり今回はテーブル設計を間違えてて、それは君がインデックスが何たるかを理解してないから
勿論追加でインデックス張ればクエリは高速にはなるけども、修正の仕方が正しいわけではないよ
上下前次1-新書関写板覧索設栞歴
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル
ぬこの手 ぬこTOP 0.029s