キーで join (map 利用)

注文のデータに、名前は書かれていない

注文 1 件ごとに持っているのは user_id という番号だけで、名前は入っていません。手を抜いたわけではなく、名前を注文側にも書き写すと、改名が起きたときに過去の注文を全部直す羽目になるからです。名前は 1 か所に置いて、注文側は番号でそこを指す。この「別の一覧の目印を指しているだけの値」を外部キーと呼びます。

そのぶん、画面に名前を出すときは取りに行く必要があります。素直に書くと、注文 1 件ごとにユーザー一覧を先頭から見ることになります。

動きはします。テストも通ります。ただし、ユーザーが 10 万人、注文が 100 万件になると比較の回数は掛け算で効いてきて、1000 億回に届きます。第 3 章で見た二重ループの重さがそのまま出てくる形です。

探すのをやめて、先に引ける形を作る

内側のループは「この番号の人は誰か」を毎回ゼロから調べ直しています。一度調べた結果を捨てているのが無駄です。番号から名前を引ける表を先に 1 回だけ作っておけば、あとは一発で引けます。

内線番号で言えば、こういうことをしておく形です。

辞書は、中に何件入っていても 1 件を引く時間がほぼ変わりません。作るのに n 回、引くのに m 回で、合計は n + m に収まります。100 万件でも待たされません。データベースが JOIN を実行するときも、内部ではこれと同じことをしています。hash join と呼ばれる古典的な手です。

無い番号を引いたときの振る舞いが、言語で違う

Python はその場で落ちます。JavaScript は undefined を返して黙って進むので、名前の欄が空のまま画面に出ます。落ちるほうが親切なこともあれば、止まると困ることもあります。

今回の課題では、対応するユーザーが必ず存在する前提でかまいません。ただし実務では、退会したユーザーの注文だけが残っている状態は普通に起きます。既定値を入れるのか、その行を出さないのかを決めておいてください。

やってみよう

joinOrders(users, orders) を完成させてください。

1. users から、user_id を渡すと name が返る辞書（JavaScript なら Object）を 1 回だけ作る
2. orders を 1 周し、各注文の user_id でその辞書を引いて名前を得る
3. name order_id amount の 3 つを持つ形にして並べる。並び順は orders のまま変えない

冒頭の二重ループでもテストは通ります。通ってしまうので、通ったあとに「辞書を先に作る形になっているか」を自分で見直してください。

1. users から user_id をキー、name を値とするマップ（dict / Object）を作る
2. orders の各要素から user_id で name を引いて { name, order_id, amount } を生成する
3. 出力の並び順は入力 orders の順番を維持する