mySQL 和一般数据库规范化问题答案

【问题标题】：mySQL and general database normalization questionmySQL 和一般数据库规范化问题
【发布时间】：2011-02-06 05:07:45
【问题描述】：

我对标准化有疑问。假设我有一个处理歌曲的应用程序。

首先我想这样做：

Songs Table:
id | song_title | album_id | publisher_id | artist_id

Albums Table:
id | album_title | etc...

Publishers Table:
id | publisher_name | etc...

Artists Tale:
id | artist_name | etc...

然后当我想到规范化的东西时。我想我应该去掉歌曲表中的“album_id、publisher_id和artist_id，并将它们放在这样的中间表中。

Table song_album:
song_id, album_id

Table song_publisher
song_id, publisher_id

Table song_artist
song_id, artist_id

现在我无法决定哪种方法更好。我不是数据库设计方面的专家，所以如果有人会指出正确的方向。会很棒的。

两种方法之间是否存在性能问题？

谢谢

【问题讨论】：

标签： mysql database database-design normalization

【解决方案1】：

第一个结构是混淆语义（例如，为每首歌曲编写出版商名称）。第二种结构将允许您将无效数据放入数据库中（例如，一首歌可以属于两个专辑）。以下是我从问题领域的理解和我对设计的建议：

一张专辑仅由一个出版商出版，因此您无需在每首歌曲中指定出版商，只需将 相册表中的 publisher_ID。此外，如果您将 artist_ID 保留在 Songs 表 中，您的每首歌曲一次只能有一位艺术家；但是通过将 song_ID 和 artist_ID 放在一个链接表中，您可以为一首歌曲拥有多个艺术家（例如 2 位歌手一起演唱一首歌曲的时间）。 publisher_id 转到 albums 表，因为每张专辑都由一个出版商出版。此外，对于表名，始终建议使用单数形式。

这是我建议的设计：

Song Table:
id | song_title | album_id | ...

Album Table:
id | album_title | publisher_id | ...

Publisher Table:
id | publisher_name | ...

Artist Table:
id | artist_name | ...

Song_Artist Table:
song_id | artist_id | artist_role | ...

【讨论】：

【解决方案2】：

这取决于。如果您可以保证某首歌曲始终属于单曲专辑，请采用第一种方法。如果没有，您有一个 n 对 n 关系并且需要一个连接表：这是您的第二种方法。就标准化而言，两者都完全可以。

重要的是您设计数据库的方式可以将您的数据映射到它。

不要担心这里的性能。性能更多地取决于您优化索引的方式和查询的外观，而不是是否必须再执行一次连接操作（您的第二种方法，连接表，在每个查询中都需要一次连接）。

【讨论】：

【解决方案3】：

忘记性能问题。问题是这个模型是否正确地表示了数据？

中间表称为“联结表”，当您可以建立多对多关系时，它们很有用。例如，如果您将歌曲“We Are the World”存储在您的数据库中，那么您将拥有很多该歌曲的艺术家。这些艺术家中的每一个还负责创作许多其他歌曲。因此，要正确表示数据，您必须使用联结表，就像您在第二个版本中所做的那样。

【讨论】：

【解决方案4】：

歌曲可以出现在多张专辑中。想想最热门的发行。缩小技术垃圾并考虑应用程序（或数据库）的实际使用情况很重要。

【讨论】：

取决于设计。一个可能的设计决定是不要让歌曲出现在一张以上的专辑中，出于某些原因……也许这首歌是在最热门的发行版中重新制作的，而您不想将其与原始专辑相关联。也许您想忽略那些真正出现在不同专辑中的极少数歌曲？重要的是：必须在设计时考虑在使用数据库之前这些事情。

【解决方案5】：

我会坚持第一个，原因有两个：

一首歌只与一个专辑、一个出版商和一个艺术家相关联，因此您不需要为它们创建单独的表（例如，如果一首歌可以有多个艺术家，则创建 song_artist 表)。
效率更高。使用第二种方法，您需要进行一些连接。

【讨论】：

只是出于好奇，为什么是-1？