具有多个类别类型数据库架构的产品

Question

我想存储有关歌曲文件的信息，这些文件按以下类别分类：
1.流派，例如流行，摇滚，古典等
。2.使用乐器，例如钢琴小提琴等
。3.艺术家
每首歌曲都有许多乐器。每首歌都有很多歌手。
因此，所有关系都是多对多的。我该如何实施？在歌曲实体和这三个类别类型的实体之间建立多对多关系是个好主意吗？还是我应该只有一个继承那些子类别的类别实体？
提前致谢

Answer 1

乐器和艺术家都是“具有”关系的例子。该类型是“是”关系的一个示例。在关系数据库设计中，Has-a和Is-
a关系的建模完全不同。歌曲是流行歌曲，或者歌曲是摇滚歌曲。（我想这首歌既可以流行又可以是摇滚，但是在您的描述中并不清楚）。

Has-a关系更为常见，通常在任何好的教程中都会涉及到。在这些相同的教程中，通常不会对Is-a关系进行足够的介绍。如果要获取有关is-
a关系的ER建模的文章，请查找“一般化/专业化”。这将解释如何描述这些关系之一，而不是如何设计适合的表。

如果您熟悉对象建模，则最简单的概念称为类/子类模式（也称为类型/子类型）。这很简单，但是取决于对继承的内置支持。这种支持通常存在于任何对象系统中，并且为您完成了大多数艰苦的工作。如果您正在设计一个关系数据库，您将面对一个事实，即关系模型不直接支持继承。这意味着除非您愿意使用SQL方言中可用的SQL扩展名，否则您必须设计表来模仿继承的好处。

这两个标签的名称已知两种相对标准的设计： 单表继承
类-表继承

您可以通过阅读每个标签的“信息”标签来获得简要说明。通过查找Martin Fowler对这两种模式的处理，您可以获得更好的描述。

单表解决方案将帮助您为所有歌曲文件创建一个表，其中的列与任何或所有类别相关。

类表解决方案将帮助您为歌曲文件设计一个表，为每种流派设计一个表。如果您使用共享主键技术，从而使流派表中的每个条目从歌曲文件表中的相应条目中“继承”其ID，将很有帮助。当您插入新的歌曲文件时，必须通过额外的编程使这种继承发生。

哪一个更好？这取决于您的情况。你决定。