私は著者と本の間に n 対 m の関係を持っています。これをモデル化するために私が検討している 2 つの可能性があります。
最初の可能性は、明示的な n 対 m の関係です。
テーブル作成者
ID Name
1 Follett
2 Rowling
3 Martin
テーブルブック
ID Title Category Logic Time
1 A Dance with Dragons Fantasy 1
2 Harry Potter Fantasy 3
3 The Key to Rebecca Thriller 2
4 World without end Drama 4
テーブル book_author
authorId bookId
1 3
2 2
3 1
1 4
2 番目の可能性は、書籍に著者 ID を保存することです。編集1冊の本に複数の著者がいる場合、著者ごとに1回本を入力する必要があります.
テーブル作成者
ID Name
1 Follett
2 Rowling
3 Martin
テーブルブック
ID Title Category Logic Time AuthorId
1 A Dance with Dragons Fantasy 1 3
2 Harry Potter Fantasy 3 2
3 The Key to Rebecca Thriller 2 1
4 World without end Drama 4 1
特定の著者 (ID 1 の Ken Follett) について、彼が最初に出版した本を見つけたいとします。
最初のケースでは、クエリは次のようになります。
select * from books b join
book_author ba on b.id = ba.book_id
where ba.author_id = 1
order by b.logic_time asc;
2 番目のケースでは、クエリは次のようになります。
select * from books b
where a.author_id = 1
order by b.logic_time asc;
著者テーブルとのさらなる結合を避けるために、上位システムに著者の ID を保存しています。私は著者の詳細にはまったく興味がありません。システムには、著者よりもはるかに多くの書籍が存在することが予想されます。
「よりクリーン」であるため、最初のオプションを選択する傾向があります(編集:本のエントリを重複させる必要はありません)が、この決定を正当化するのに問題があります。
パフォーマンスの観点から推奨されるものは何ですか? 結合により、最初のオプションが遅くなるはずだと推測しています。
最初のオプションを高速化するために作成できるインデックスについてはどうでしょうか?