DBロジックのテストコードにおけるプライマリキーと外部キーの設計

はじめに

テストコードでDBロジックを検証する際、プライマリキー（Primary Key, 以下PK）や外部キー（Foreign Key, 以下FK）の値の振り方に工夫をすることで、テストの可読性やメンテナンス性が向上します。今回は、私が普段採用している関連性が一目で分かるID設計について紹介します。

サンプルデータ設計

以下は customers、orders、order_details の3つのテーブルを例にした設計です。

customers テーブル

id	name
1	あああ
2	いいい

orders テーブル

id	customer_id
11	1
12	1
21	2
22	2

order_details テーブル

id	order_id	price
1101	11	298
1102	11	399
1201	12	1980
2101	21	19800
2201	22	99
2202	22	34800

設計の意図

PKやFKの値を単にインクリメントするのではなく、関連性がひと目で分かるような構造にしています。例えば、orders のIDは、customer_id を十の位に持たせています。

• 11, 12 は customer_id = 1 に紐づいている注文
• 21, 22 は customer_id = 2 に紐づいている注文

また、order_details のIDも同様に工夫されています。

• 1101, 1102 は order_id = 11 の注文詳細
• 1201 は order_id = 12 の注文詳細

このようにすることで、IDを見ただけで関連性が把握でき、デバッグやテストの確認が容易になります。

メリット

1. 関連性が一目で分かる

外部キーの参照先を考える時間が減ります。IDを見れば自然と親子関係が想像でき、テストコードの読み解きがスムーズです。

2. クエリの意図が分かりやすい

例えば、order_id = 21 を検索した時、customer_id = 2 の注文だとすぐに理解できます。複雑なジョインをしなくても、ある程度の流れが把握できます。

3. デバッグが容易

テストが失敗した場合、該当のIDを見ればどの顧客のどの注文かがすぐ分かります。逆引きが簡単で、原因調査の速度が向上します。

注意点

• IDの管理を手動で行う必要があるため、意図的な設計が必要
• 自動生成する場合には、生成ルールの統一が求められる

まとめ

テストコードにおけるDBロジックの確認は、データの関連性が明確であればあるほどスムーズです。プライマリキーや外部キーの設計を工夫することで、テストの読みやすさやデバッグのしやすさが格段に向上します。ぜひ一度試してみてください。