（書き途中）
「RDB（リレーショナルデータベース）を君は理解しているか？」を調べるのに使われる話題としては多対多（N対N）のデータ構造の他にN+１問題があることに最近になって気がついた。
※多対多のテーブル構造についてはリンク先などを見てください。
…このあたりはどうしてもシステム開発をやっていて出くわした経験がないとイメージがしづらいところで、経験したことがない人でなければ分からないナレッジ（経験則・経験的知識）になりやすいのかもしれない。
※逆の言い方をするとRDB設計をしっかりと行うためにはこの部分の理解が”やや必須”（なにが何でも知っておかなきゃダメと言い切る自信もないので”やや必須”という表現にしている）であり、ソロでこなす（知識を正しくもち合わせて問題解決を図る）には、かなりの難所ではないだろうか。
ORMの設定だけで乗り切るとしても、これを問題を問題として認識していていない限り正確な対処ができないのではないだろうか。余談であるが、現代では何でも一人で学ぶことが増えているが、このへんのナレッジを学習する機会がお留守になりがちであるだろうし、何も分かっていない組織（組織全体の底上げを行って社会に貢献しようとしていない一部のSES企業）ほど、この部分のナレッジ共有を無視しがちではないだろうか。
まあ、それはさておき重要な知識であると言いたいのがコレ↓かなりさっぱりとしたメモなので詳しく知りたい方は専門書に当たって欲しいところ。もしくは先輩へ聞くところ。食う寝る処に住む処。パイポパイポ、パイポのシューリンガン、ポンポコピーのポンポコナーの…
N+1問題と多々多（N対N）のデータ構造の複合した問題に出くわす
…とある企業のシステム開発室。わりと若い人が、N+1問題とN対Nデータ構造の問題にたまたま目にすることがあったとさ。
こんな問題であったとさ。
ユーザIDのみをもったリストがN件ある。
例）
{user_id :1, user_id: 2, user_id :3, … user_id : n}
…ここからDBを引いて最新のユーザ情報を取得したい。ところが、N回クエリを呼び出さねばならないため処理は非効率だ。リストのデータ量が増えればデータ取得は計算機の性質上からいって”やらないほうがいい”。そもそもリストN件が作り出されたところから、データ構造ならびにシステム仕様を見直さなければならない（これが、N+1問題だと私は理解している）
詳しく前提条件を調べたところ、このユーザIDとユーザ詳細情報を持っているリストは、システム要件的にN対Nのデータ構造だったので、N対Nのデータとしてユーザの詳細情報を連結した上で、データ取得ならびに更新がかけられるようにしたとのこと。
まとめ
別に大したことはないのだが、N＋１のNとN対NのNは通常別問題だが、このように複合した場合は同値にもなりうるんだなー。
複合した問題としても扱える＝複合演習問題にもなるな（そうする必要もないかもしれないが）などという、極めてどうでもいいことを思った次第。
もしこの仕事を投げるPM役割の人が、このあたりの知識が無い場合は、その辺に明るい技術の責任者に尋ねるのが望ましい。正しい評価ができる人がいないと、間違ったものが出来上がる。いずれにしても、技術の部分をコントロールするのがドダイ無理なら”仕様書”ではなく”要求定義書”をプログラマに投げてコーディングしてもらうことになるが、正確に処理機構を把握していなければいずれにしても高リスク。そんな状態でプロジェクトの責任者なんてやってられないな（ぼやき）
コメント