相似数据的规范化与非规范化数据库答案

【问题标题】：Normalised vs. denormalised database for similar data相似数据的规范化与非规范化数据库
【发布时间】：2016-07-23 08:32:57
【问题描述】：

我打算建立一个数据库来存储大量有关音乐的数据。我将歌曲特定信息存储在db_song 表中。我还想存储 genres、instruments、samples 和 playlists。因为一首歌可以有多种流派、乐器、样本和播放列表，所以最大的问题是：

这样做是否更有意义：

数据库会经常更新，但用户会更频繁地请求数据。

感谢您的帮助。

编辑：

正如 Amit 所建议的那样，使用上面的设置，会有很多重复数据。将流派和乐器值以及播放列表标题存储在不同的表中，并将流派、乐器和播放列表的关系（项目到歌曲）存储在另外 3 个表中。

所以新场景：

【问题讨论】：

性能只是数据复制的一方面。另一方面是数据管理本身。您将希望您的大部分数据管理实现自动化。但是有些事情你必须手动完成。如果您不小心，数百万行的手动处理将占用您所有的时间。非托管数据会腐烂。

【解决方案1】：

“歌曲”可以有 0 个或 1 个或多个流派、乐器、样本和播放列表。因此，少于 5 个表不有意义。

此外，其中许多是“多对多”的。例如，一个播放列表可以包含多首歌曲；一首歌可以在许多播放列表中。为了处理这种情况，您需要一个带有 song_id 和 playlist_id 的额外表来建立多对多“关系”。

另一方面，“流派”是一组可能有十几种可能性的集合——“摇滚”、“古典”……您可能不需要针对流派的表。相反，每首歌曲（以及每个播放列表？）都可以包含一个带有流派的 ENUM 或 SET。并且不值得拥有多对多映射（在这种情况下）。

为了帮助充实架构，请考虑SELECTs 的外观。

【讨论】：

【解决方案2】：

当您说“大量数据”时，您是指多少数据？几百万首歌曲和相关元数据不应该对标准数据库设置造成任何真正的性能问题。

我建议您以第 3 范式 (3NF) 设计您的数据库，从而使用 4 个或更多单独的表。对于非规范化结构（一个大表），行中将存在重复信息，并且与规范化结构相比，更新成本会更高。

对于数据读取/分析的需求，如果需求是针对具有历史数据需求的复杂数据分析，那么值得考虑在操作系统之上构建数据仓库。如果数据要求很简单（连接这些表以获取特定歌曲、艺术家或流派的信息），那么规范化数据库应该能够轻松地回答它们。

【讨论】：