R2 午後2問1設問1(1)について
ジャムおじさんさん
(No.1)
模範解答が「地域コード、世帯区分」ではなく、「世帯区分、地域コード」となっている理由がピンと来ていません…。住居テーブルの定義順)「地域コード、世帯区分」)のままではなく、索引の定義では逆転させる理由は何でしょうか。
1問目という初歩的な質問で非常にお恥ずかしいですが教えていただけると嬉しいです…。
1問目という初歩的な質問で非常にお恥ずかしいですが教えていただけると嬉しいです…。
2023.08.05 15:58
gawaさん
(No.2)
世帯区分 だけで索引使えるようにするためです。
住居において、主キーと外部キーは索引があるので、世帯区分に何かしら索引が必要になります。また、処理2では地域コードと世帯区分の両方が一致する条件も必要です。なので複合索引が必要。
問題だと、新たに定義する索引はひとつだけ、と指定されてます。なので、世帯区分、地域コード の複合索引を作ります。
地域コード、世帯区分 の順番だと、世帯区分だけで索引が使えません。複合索引というのは、そういうもんです。(定義順からソートされてくので、二番目以降の属性の順序は保証されません)
住居において、主キーと外部キーは索引があるので、世帯区分に何かしら索引が必要になります。また、処理2では地域コードと世帯区分の両方が一致する条件も必要です。なので複合索引が必要。
問題だと、新たに定義する索引はひとつだけ、と指定されてます。なので、世帯区分、地域コード の複合索引を作ります。
地域コード、世帯区分 の順番だと、世帯区分だけで索引が使えません。複合索引というのは、そういうもんです。(定義順からソートされてくので、二番目以降の属性の順序は保証されません)
2023.08.05 19:55
gawaさん
(No.3)
ちなみに「だったら、索引1:世帯区分、索引2;地域コード、世帯区分 みたいに索引2作ってもいいじゃないか。なんで1つだけしか作れない前提で問題だすんだ」と思われるかもしれませんが、索引はInsert/Updateの際に再構成するのに時間がかかるのでパフォーマンスが悪くなります。なので、極力、索引の数は必要最低限だけ作るのがセオリーとなります。
索「読み込みの性能があがるんだったら、とにかく作りまくればいいじゃん!」ということではなく、「Insert/Updateの際に再構成するのに時間がかかる」ので、頻繁にInsert/Updateがある場合は害になることがある・・・・は過去問の物理設計での定番ですので、覚えておくとよいです。
索「読み込みの性能があがるんだったら、とにかく作りまくればいいじゃん!」ということではなく、「Insert/Updateの際に再構成するのに時間がかかる」ので、頻繁にInsert/Updateがある場合は害になることがある・・・・は過去問の物理設計での定番ですので、覚えておくとよいです。
2023.08.06 10:35
ジャムおじさんさん
(No.4)
gawaさん、丁寧な回答ありがとうございます。回答をもとに色々と調べて理解できました、助かりました!!
2023.08.07 18:25
返信投稿用フォーム
スパム防止のためにスレッド作成日から30日経過したスレッドへの投稿はできません。