第五回
データベース × PayPay

CH 014つのテーブルで読み解く全体像

ECサイトやスマホ決済を扱うシステムの裏側では、データベースが大量のデータを整理して保存している。といっても構造は意外とシンプルで、ユーザー・店舗・商品・購入履歴の 4 テーブルが基本形。今回は PayPay 決済を題材に、この 4 つがどう設計され、どうつながるかを読み解いていく。

読み進める前に：基本用語

データベースはテーブル（表）の集まりでできている。横 1 行分のデータがレコード、縦の項目がカラム。そしてテーブル同士をつなぐ鍵になるのが、次の 2 種類の「キー」だ。

CH 02User — ユーザー管理テーブル

「誰が」を管理する中核テーブル。アプリにログインする全ユーザーの基本情報を保持し、決済時には本人の PayPay アカウントと紐づける。

設計のポイント

• user_id は他テーブルから参照される主キー。ここが全ての起点になる
• PayPay アカウント情報は paypay_account_id として別カラムで保持する
• 個人情報を扱うため、パスワードの hash 化・暗号化が必須

スキーマ：users

CH 03Company — 会社・店舗管理テーブル

「どこが」を管理するテーブル。商品を販売する企業や店舗の情報を保持し、PayPay 加盟店 ID によって決済時に売上の振込先を特定する。

設計のポイント

• Product テーブルから参照される側になる（1 店舗 : N 商品 の関係）
• paypay_merchant_id で「どの加盟店への支払いか」を識別する
• 1 つの店舗は複数の商品を持てる。商品側に店舗情報を書き写さないのがコツ

スキーマ：companies

CH 04Product — 商品管理テーブル

「何を」を管理するテーブル。販売する商品の名称・価格・在庫を保持し、どの会社が販売しているかを外部キーで紐づける。

設計のポイント

• company_id で店舗テーブルを参照する。ここで初めて外部キー (FK) が登場
• price は決済金額の根拠になる値。型は誤差の出ない DECIMAL を使う
• 在庫（stock）は規模が大きくなったら別テーブルに切り出すことも検討する

スキーマ：products

CH 05Purchase — 購入日時テーブル × PayPay

「いつ・いくらで」を記録し、4 テーブルすべてを結ぶハブ。User・Company・Product への外部キーを 3 本持ち、さらに PayPay の決済 ID がここに保存されることで、決済システムとデータベースが連動する。

スキーマ：purchases

CH 06まとめ — テーブル同士のつながり

全体を俯瞰すると、Purchase テーブルが 3 つのマスタ（User / Company / Product）をつなぐハブになっていることがわかる。各マスタから見ると Purchase とは 1 : N の関係——1 人のユーザーは何度も買い、1 つの店舗・商品は何度も売れるからだ。

「関係」は SQL でこう辿れる

テーブルを分けて ID でつないでおくと、決済 ID ひとつから「誰が・どこで・何を・いくらで」買ったかを 1 本のクエリで辿れる。

-- 決済IDから購入の全体像を辿る
SELECT u.name, c.name AS shop, p.name AS product, pu.amount, pu.purchased_at
FROM purchases pu
JOIN users     u ON pu.user_id    = u.user_id
JOIN products  p ON pu.product_id = p.product_id
JOIN companies c ON pu.company_id = c.company_id
WHERE pu.paypay_transaction_id = 'pp_8f3a1c…';