[過去ﾛｸﾞ] スレ立てるまでもない質問はここで 165匹目 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
314: (ﾜｯﾁｮｲ ff84-pmcO) 2023/12/10(日)14:06 ID:Ne0vvx410(1/2) AAS
>>312
申し訳ありません、誤解が生じました。確かに、私の前回の説明は一般的な場合に当てはまりますが、特に文字列の場合、`where b=値2` のクエリが効率的になるかどうかはデータの具体的な並びに依存します。
文字列の場合、B-Treeの挙動が通常の数値とは異なります。例えば、`ああ`、`あい`、`あう`などが順序通りに格納されることで、`where b='い'` のクエリは特に高速になります。これはB-Treeが文字列においても順序を保ちながらデータを格納するためです。
ただし、文字列の場合でも、全くの一般性があるわけではありません。文字列のソートは、通常の辞書順ではなく、各文字のバイトレベルの比較に基づいていることも考慮する必要があります。
そのため、データの実際の配置や使用しているデータベースシステムによっては、特定のクエリの性能が異なることがあります。文字列データにおいても最適なインデックス戦略は、具体的なデータとクエリによって変わることがあるので、実際のデータや使用状況を元に検討することが重要です。
315: (ﾜｯﾁｮｲ ff84-pmcO) 2023/12/10(日)14:08 ID:Ne0vvx410(2/2) AAS
>>313
おっしゃる通り、複合カラムの場合、特に「条件にaを指定せずにbだけを指定した場合」、B-Treeの探索が効率的でない場合があります。
複合カラム `(a, b)` のB-Treeでは、`a` でソートされ、同じ `a` の中で `b` がソートされている状態です。そのため、`where b=値2` のようなクエリが効率的になるのは、同じ `a` 内において `b` の値が連続的に格納されている場合に限られます。
しかし、もし `a` の値が異なる場合、`b` の値も異なる箇所に格納され、深さが増加し、効率が損なわれる可能性があります。したがって、複合インデックスの効果はデータの分布に強く依存します。
一般的に、複合インデックスが効果的なのは、クエリで指定された条件が複合インデックスの順序に合致する場合です。もし `a` を指定せずに `b` だけを指定するケースでデータが分散して格納される場合、B-Treeの探索が非効率的になる可能性があります。その際は、単独の `b` に対する単一カラムインデックスを検討することが適している場合があります。
316: (ﾜｯﾁｮｲ 37ec-RTrI) 2023/12/10(日)14:17 ID:+Ev0uxFD0(1) AAS
ChatGPT使ってないとGPT回答を見分けられないのか
チューリングテストクリアだな
317(1): (ﾜｯﾁｮｲ 9f4b-7MMK) 2023/12/10(日)16:08 ID:oYKusLHl0(1) AAS
SQLITEやOracleではINDEX SKIP SCANを使うので左端列を指定しなくてもインデックスが採用される
もちろん左端列のみを指定するより性能は劣る
SQLServerあたりだと左端列を指定しないケースではインデックスは使われない
318(2): (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)18:25 ID:V/86XK6XM(1) AAS
[1] あ、い、う の三文字を2個並べた組み合わせを
キーに持つとして、3*3=9 個のキーを持つと
すると、B-Tree は、木の根が1つで、
1文字目で3つに枝が分かれ、別れた先
の2文字目でさらに3つに枝が分かれます。
1文字目をa, 2文字目をbとします。
図が書けないので、フォルダのように表すと、
/あ/あ (1)
/あ/い (2)
/あ/う (3)
/い/あ (4)
/い/い (5)
/い/う (6)
/う/あ (7)
/う/い (8)
/う/う (9)
となります。
[2] where a=あ and b=い
とした場合、たった一度の探索で(2)
に辿り着けます。
[3] where a=い
とした場合は、(4),(5),(6)ですが、それらは、「第一関節」の
同じ一本の枝「い」に属すのでとても効率的に探せます。
[4] where b=い
とした場合、(2),(5),(8)の三か所を探索する必要がありますが、
第一関節レベルから異なる枝に属しているので、
第二関節に行った後で第一関節まで「戻る」ような動作が必要になります。
[まとめ]
実際の探索では、「戻る」わけではないんでしょうが、
aだけを指定した場合と、bだけを指定した場合とでは、探索回数が3倍の違いが
出てきますよね？
319: (ﾜｯﾁｮｲ 979f-g9yR) 2023/12/10(日)18:55 ID:szFLrNg10(1) AAS
INDEX RANGE SCANだな
320(1): (ﾜｯﾁｮｲ 9f79-1KRD) 2023/12/10(日)21:44 ID:yZwJDRXW0(1/2) AAS
>>318
B木って部分探索のアルゴリズムじゃないけど
トライ木辺りと勘違いしてないか
321: (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/10(日)22:38 ID:sxH1jiAFM(1) AAS
>>320
本当はこうではないんですが、これとよく似た
事が起きていると思うんです。
322: (ﾜｯﾁｮｲ 9f79-1KRD) 2023/12/10(日)23:36 ID:yZwJDRXW0(2/2) AAS
長ったらしいから3行で質問をまとめる努力をして欲しい
さもなくばお前が思うんならそうなんだろうお前ん中ではなという感想を述べさせてもらう
323(1): (ﾜｯﾁｮｲ 7f01-a+/s) 2023/12/10(日)23:59 ID:p7J4kGbi0(1) AAS
>>318
B-Treeはそういうのじゃない
ページサイズの一定割合に収まるだけのレコードがルートを含めたインデックスノードにも詰められていく
page 1 [ああ〜いい]
/
いう
\
page 2 [いう〜うう]
>>317の書いてるINDEX SKIP SCANがDBMSやデータの状況によって採用されるケースなら
インデックスがあったほうが速いということになるが採用されなければテーブルスキャンなのでインデックスなくても同じ
INDEX SKIP SCANは複合インデックスの先頭列の値の種類が少ない場合じゃないと非効率
324: (ﾜｯﾁｮｲ 7f01-a+/s) 2023/12/11(月)00:02 ID:+qYlbChh0(1) AAS
全角スペースにした
page 1 [ああ〜いい]
/
いう
\
page 2 [いう〜うう]
325: (ﾜｯﾁｮｲ d701-7tbx) 2023/12/11(月)00:14 ID:JY+EfkBo0(1) AAS
bカラムだけのパターンでも効くことあるんだ
sql serverしか知らないからダメだと思ってた
でも基本はbカラムだけで高速化を狙うならbカラム単体でもインデックス張るべきだと思うけど
326: (ｵｲｺﾗﾐﾈｵ MM2b-FJ+M) 2023/12/11(月)10:45 ID:TsCEY1+2M(1) AAS
>>323
あなたはB-Treeを理解できてない。
俺は天才だからわかる。
327: (ﾜｯﾁｮｲ 1f9e-C3j7) 2023/12/12(火)00:59 ID:C12JHku00(1) AAS
確か、Ruby on Rails で見た
X, Y, Z 列にインデックスを付ける場合、
複合インデックス、XYZ, YZ, Z を付けるとか
文字列は先頭か末尾指定でしか、インデックスが使われないとか。
つまり、文字列の中ほどに含むと言うのがダメ
328: (ｽｯﾌﾟ Sd3f-v3qT) 2023/12/12(火)01:12 ID:HomtdY1ed(1) AAS
馬鹿の妄言
Ruby
329: (ﾜｯﾁｮｲ 1701-1GQ9) 2023/12/12(火)20:38 ID:nNQd25Q50(1) AAS
githubの中身はRailsなんだね
330: (ﾜｯﾁｮｲ 17c7-C3j7) 2023/12/13(水)00:02 ID:eFIo8YKe0(1) AAS
Github は、Rails からGo へ移行していると聞いた
YouTube で有名な雑食系エンジニア・KENTA が、
初心者のキャリアパスは、Rails → Go のみと言ってる
Ruby/Goの神・HashiCorp のMitchell Hashimoto もそう。
Ruby製のVagrant → Go製のTerraform。
今は、Goプログラマーしか求めていない
一方、Shopify, Gitlab は、Goへ移行しない
331: (ｽｯﾌﾟ Sd3f-v3qT) 2023/12/13(水)01:13 ID:Z8G46vVkd(1) AAS
初心者は関わってはいけない
332: (ﾜｯﾁｮｲ 9f74-7BHq) 2023/12/13(水)06:50 ID:hoISaMFl0(1/3) AAS
どうもケンタでーす。
333: (ﾜｯﾁｮｲ 9f74-7BHq) 2023/12/13(水)06:50 ID:hoISaMFl0(2/3) AAS
初心者のキャリアパスは、Rails → Go のみ、って感じですね。
334: (ﾜｯﾁｮｲ 9f74-7BHq) 2023/12/13(水)06:52 ID:hoISaMFl0(3/3) AAS
人生は短いですので、若い時間はナンパしたりクラブいったりしましょうね、って感じですね。
ではまたお会いしましょーう。
335: (ﾜｯﾁｮｲ f35a-v2wD) 2023/12/19(火)16:36 ID:4azPkHSc0(1/2) AAS
cursorというエディタを使っているのですが、凄い細かい所で気になってしまう箇所があります。
関数等を作成したときの中カッコ｛｝をエンターキーで改行した時に終わりの方だけ改行されてしまい、
関数()｛
}
といった形になってしまいます。書式設定を確認してみたのですが設定項目を見つけられませんでした...
エンターキー1回で
関数()
{
｝
という風に出来るようにしたいのですがどこを設定したら良いのでしょうか...あとセミコロンを入力したら自動的に行の最後に入力されて整形してくれる機能ってありますか...?
336: (ﾜｯﾁｮｲ 924a-s4TD) 2023/12/19(火)17:12 ID:hNriuvdH0(1) AAS
K&Rあたりだと関数宣言のときだけブレース前に改行入れて、ifやelseだと改行入れずに行末に置くんだよな
一貫性ないけど、かといって
}
else
{
も冗長すぎるしわからんこともない
Javaの流行期を経て行末ブレースがデファクトスタンダード化した印象ある
337: (ｱｳｱｳｸｰ MM87-ztdx) 2023/12/19(火)17:45 ID:kFMxEOALM(1) AAS
c#もそうなので廃れたとかないと思うけど
338: (ﾜｯﾁｮｲ f35a-v2wD) 2023/12/19(火)19:38 ID:4azPkHSc0(2/2) AAS
調べたらBSDスタイルって言うんですね...
K&Rというスタイルにどうしても慣れなくて探し回ったんですが無さそうだったんで大人しくVSCodeに帰ろうと思いますありがとうございました...
339(2): (ﾜｯﾁｮｲ 136e-fH6R) 2023/12/20(水)12:16 ID:/dCibiYH0(1) AAS
ワイルドカードの指定が空だった場合の挙動ってどうあるべきなの？
"AAA"だったら"AAA"にのみマッチするように
""だったら""にのみマッチするのが正解？
340: (ﾜｯﾁｮｲ 72a7-e8vO) 2023/12/20(水)12:37 ID:eSxhSkCc0(1) AAS
そりゃそうだろ
341: (ﾜｯﾁｮｲ d64a-InpM) 2023/12/20(水)15:19 ID:caZsSM6E0(1) AAS
>>339
用途というか対象によるのでその情報だけじゃわからんよ
例えばリストをフィルタリングするときならAAAと入力されればAAAがどこかに含まれてればOKにすることはよくある
入力が空なら何もフィルタリングしないので全部表示したままにする
342: (ﾜｯﾁｮｲ 63c5-jnAL) 2023/12/20(水)15:20 ID:0h1pZh3H0(1) AAS
もう何年もマッチすってないや
343: (ﾜｯﾁｮｲ 9235-s4TD) 2023/12/21(木)10:05 ID:Ftl9RUYK0(1) AAS
>>339
その検索が部分一致なら全てにヒットするし完全一致なら空文字列にしかヒットしない
これは文字種としてワイルドカードや正規表現が使えるかどうかとは無関係で独立して決まる
上下前次1-新書関写板覧索設栞歴
あと 659 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.015s