数据库设计和ERD，用于相当复杂的音乐品味共享网络应用程序

Question

我正在尝试为音乐品味共享网络应用程序设计数据库。

我几乎从不做Db设计/架构，并且认为我会从SO用户那里得到一些帮助，希望我的问题可以成为“好”Db设计实践的一个很好的例子。

仅供参考：ERD是使用 MySQL Workbench 绘制的，这是一款免费软件。

以下是我的要求以及我如何在Db架构中表示

• 用户拥有凭据＆amp;帐户/个人资料（电子邮件，fName，lName，等等） - 所有这些都在USER_DETAILS表格下

• 用户可以拥有角色＆amp; ＆安培;一些用户可以拥有相同的角色 - 因此USER_DETAILS和{}之间的多对多关系ROLE表

• 用户可以拥有图片 - 因此USER_DETAILS＆amp;之间的一对多关系USER_IMAGE表

• 用户可以拥有许多徽章＆amp;几个用户可以拥有相同的徽章 - 因此USER_DETAILS和{}之间的多对多关系BADGE表

• 用户的曲目可以有很多声誉历史记录。信誉历史记录仅匹配一个特定用户的跟踪 - 因此USER_DETAILS_TRACK＆amp;之间的一对多关系REPUTATION_HISTORY表

• 用户可以拥有多个曲目＆amp;几个用户可以拥有相同的轨道 - 因此USER_DETAILS和{}之间的多对多关系TRACK表

• 用户可以在每个音轨上添加标签＆amp;多个用户可以在每个跟踪中使用相同的标记 - 因此USER_DETAILS_TRACK和＆amp;之间的多对多关系TAG_2表

• track在TRACK表

下表示

• 赛道可以有几位艺术家和一个艺术家可以在几个轨道 - 因此TRACK＆amp;之间的多对多关系。 ARTIST表

• track可以有几个版本＆amp;一个版本可以（通常）有几个轨道 - 因此TRACK＆amp;之间的多对多关系。 RELEASE表

• 发布有一个release_type＆amp; release_type可以在许多版本中 - 因此RELEASE_TYPE＆amp;之间的一对多关系。 RELEASE个表格（发布类型为专辑，EP，LP，单个＆amp;等等）

• 跟踪可以有评论 - 因此TRACK＆amp;之间的一对多关系COMMENT表

• 曲目可以有几个标签＆amp;一个艺术家可以在几个轨道 - 因此TRACK＆amp;之间的多对多关系。 TAG_1表

你一定注意到我复制了TAG表有TAG_1＆amp; TAG_2。理想情况下，我只会有一个，但我担心会在USER_DETAILS_TRACK和TRACK之间产生过强的耦合。这些{{1}}表已与多对一关系链接。

我打算保留TAG_1＆amp; TAG_2在中间层同步。

---

podiluska评论后的最新编辑

1. 关于我的数据库设计，我是否在正确的道路上？
2. 你会修改/改进什么？

非常感谢

Answer 1

除了评论中的调整外，我认为现在或多或少都存在。

您需要从Release中删除Track_ID并将其替换为Track中的Release_ID，或者使用TrackRelease表 - 具体取决于轨道是否可以在多个版本上，反之亦然。