是否应该使用子类型继承来管理与数据库中的书籍和文章相关的注释？

数据库设计：子类型继承的优点和局限性

在数据库设计中，决定是否使用子类型继承可能是一个至关重要的决定数据标准化和灵活性。让我们探讨在包含书籍、文章和笔记的模式上下文中使用子类型继承的优点和缺点。

具有共享“笔记”表的原始设计

最初，设计包括三个主要表格：“书籍”、“文章”和“注释”。书籍和文章的注释都存储在“NOTES”表中，列包括“note_id”、“note_type”、“note_type_id”和“note_content”。此设计需要在“NOTES”和“BOOKS”或“ARTICLES”之间进行 JOIN 操作来检索特定笔记。

具有单独表的替代设计

作为替代方案，设计师建议创建五个单独的表：“BOOKS”、“ARTICLES”、“NOTES” “BOOK_NOTES”和“ARTICLE_NOTES”。这种设计将书籍和文章的注释隔离到不同的表中，每个表都包含对应“BOOK_ID”或“ARTICLE_ID”的外键。

方法比较

带有共享“NOTES”表的原始设计具有简单性和减少数据冗余的优点。然而，随着笔记数量的增加，它的效率可能会降低，特别是当查询集中于仅与一种出版物类型（例如书籍或文章）相关的笔记时。

使用单独表的替代设计改进了数据组织并且无需使用 JOIN 来检索特定出版物类型的注释。但是，它引入了数据冗余，因为注释同时存储在“NOTES”表和相应的“BOOK_NOTES”或“ARTICLE_NOTES”表中。

作为妥协的超类型/子类型继承

虽然当子类型具有高度专业化的列时经常使用子类型继承，但它可能不是这种情况的理想解决方案。相反，建议采用以下方法：

1. 创建一个名为“PUBLICATION”的超类型表，其中包含书籍和文章共有的列（例如，“ID”、“

”

以上是是否应该使用子类型继承来管理与数据库中的书籍和文章相关的注释？的详细内容。更多信息请关注PHP中文网其他相关文章！