データベース内の書籍や記事に関連するメモの管理にサブタイプの継承を使用する必要がありますか?

データベース設計: サブタイプ継承の利点と制限

データベース設計において、サブタイプ継承を使用するかどうかの決定は、サブタイプ継承に影響を与える重要な決定となる場合があります。データの正規化と柔軟性。書籍、記事、メモを含むスキーマのコンテキストでサブタイプ継承を使用することの長所と短所を見てみましょう。

共有 'Notes' テーブルを使用したオリジナルのデザイン

当初、デザインには「BOOKS」、「ARTICLES」、「NOTES」という 3 つのメイン テーブルが含まれていました。書籍と記事の両方に関するメモは、「note_id」、「note_type」、「note_type_id」、「note_content」などの列を持つ「NOTES」テーブルに保存されました。この設計では、特定のノートを取得するには、「NOTES」と「BOOKS」または「ARTICLES」の間の JOIN 操作が必要でした。

個別のテーブルを使用した代替設計

代替案として、デザイナーは、「BOOKS」、「ARTICLES」、「NOTES」という 5 つの別々のテーブルを作成することを提案しました。 「BOOK_NOTES」と「ARTICLE_NOTES」。この設計では、書籍と記事に関するメモを個別のテーブルに分離し、各テーブルに対応する 'BOOK_ID' または 'ARTICLE_ID' への外部キーを含めます。

アプローチの比較

共有「NOTES」テーブルを使用したオリジナルの設計には、シンプルさとデータの冗長性の削減という利点があります。ただし、メモの数が増えると、特にクエリが 1 種類の出版物 (書籍や記事など) のみに関連するメモに焦点を当てた場合、効率が低下する可能性があります。

別のテーブルを使用した代替設計により、データ構成が改善されます。また、特定の出版物の種類のノートを取得するために JOIN を使用する必要がなくなります。ただし、メモは「NOTES」テーブルと、対応する「BOOK_NOTES」または「ARTICLE_NOTES」テーブルの両方に保存されるため、データの冗長性が生じます。

妥協としてのスーパータイプ/サブタイプの継承

サブタイプの継承は、サブタイプに高度に特殊化された列がある場合によく使用されますが、理想的なソリューションではない可能性があります。このシナリオの場合。代わりに、次のアプローチが提案されています。

1. 書籍と記事の両方に共通の列 (例: 'ID'、'

) を持つ 'PUBLICATION' というスーパータイプ テーブルを作成します。

以上がデータベース内の書籍や記事に関連するメモの管理にサブタイプの継承を使用する必要がありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。