データベース設計における親子関係の決め方

Question

注文情報を管理するためのデータベースを設計するとして、次のようなテーブルを作りました。

・注文詳細（注文したプラン、備考など） orders
・送付先情報（送り先名前、住所） shipments
・支払情報（カードの名義、下４桁の番号） payments

それぞれの関係性は１対１です。１回の注文で必ず各テーブルに１つずつデータが登録されるものとします。

各テーブルを紐付けるために親IDか子IDを持たせなければならないと思いますが、
一般的にどちらに持たせるのルールや常識などあるのでしょうか？

1. orders を親として、他のテーブルに order_id の形で持たせる

2. orders に shipment_id, payment_id を持たせる

3. orders と、それ以外の両方に ID を持たせる（例: orders.payment_id, payments.order_id）

知りたいのは今回のケースに限った設計の仕方というよりもこのような親子関係のあるデータベース全般を設計するにあたって、何を条件に、どちらにリレーション用のIDをもたせるかのルールが知りたいです。
よろしくお願いします。

Answer 1

完全に1対1対応するデータならどちら向きでもかまわないのですが、そうではないこともありえます。

• 1つの注文に対して配送先が増える、という可能性があります。
• クレジットカードでない注文が来る可能性もあります。

ということで、orderをメインとして、残りのテーブルにorder_idを持たせるほうが自然な設計ではないかと思います。

なお、3のように、「両方にキーをもたせる」と言うのは、全く同じ意味のデータが入るだけでデータ容量の無駄ですし、整合しないデータが入る危険があるなど厄介になってしまうので、通常は取らない手法です。