我想存储有关歌曲文件的信息,它们按以下方式分类：
1.流派,例如：流行,摇滚,古典等
2.像钢琴小提琴一样使用的乐器等
3.艺术家
每首歌都有很多乐器.每首歌都有很多艺人.
所以这些关系都是多对多的.我该如何实现呢？在歌曲实体和那三个类别类型实体之间建立多对多关系是否是个好主意？或者我应该只有一个继承这些子类别的类别实体？
提前致谢
1.流派,例如：流行,摇滚,古典等
2.像钢琴小提琴一样使用的乐器等
3.艺术家
每首歌都有很多乐器.每首歌都有很多艺人.
所以这些关系都是多对多的.我该如何实现呢？在歌曲实体和那三个类别类型实体之间建立多对多关系是否是个好主意？或者我应该只有一个继承这些子类别的类别实体？
提前致谢
解决方法
乐器和艺术家都是“有一个”关系的例子.该类型是“is-a”关系的一个例子. Has-a和Is-a关系在关系数据库设计中的建模方式完全不同.歌曲是流行歌曲,或歌曲是摇滚歌曲. (我认为一首歌既可以流行也可以摇滚,但在你的描述中并不清楚).
有一种关系更常见,并且通常包含在任何好的教程中.在这些相同的教程中,关系通常没有得到足够的覆盖.如果您想获得一些关于is-a关系的ER建模的文章,请查找“泛化/专业化”.这将解释如何描述这些关系之一,而不是如何设计适合的表.
如果您熟悉对象建模,则对该概念的最简单处理称为类/子类模式aka类型/子类型.这很简单,但它取决于内置的继承支持.这种支持通常存在于任何对象系统中,并为您完成大部分工作.如果您正在设计关系数据库,那么您将面对关系模型不直接支持继承这一事实.这意味着您必须设计模仿继承优势的表,除非您愿意使用sql方言中提供的sql扩展.
这两个标签的名称已知两种相对标准的设计：
single-table-inheritance
class-table-inheritance
您可以通过阅读每个标签的“信息”选项卡获得简要说明.通过查看Martin Fowler对这两种模式的处理,您可以获得更好的描述.
单表解决方案将帮助您为所有歌曲文件创建单个表,其中包含与任何或所有类别相关的列.
类表解决方案将帮助您为歌曲文件设计一个表,为每个类型设计一个表.如果您使用共享主键技术,从而使类型表中的每个条目从歌曲文件表中的相应条目“继承”其ID,将会很有帮助.当你去插入一个新的歌曲文件时,你必须通过额外的编程来实现这种继承.
哪一个更好？这取决于你的情况.你决定.
