我对标准化有疑问。 假设我有一个处理歌曲的应用程序。
首先我想过这样做：
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
现在我无法确定哪种方式更好。我不是数据库设计方面的专家，所以如果有人指出正确的方向。这太棒了。
两种方法之间是否存在性能问题？
由于
答案 0 :(得分：3)
忘记性能问题。问题是这个模型是否正确表示数据？
中间表称为“联结表”，当您可以拥有多对多关系时，它们非常有用。例如，如果您在数据库中存储歌曲“We Are the World”，那么您将拥有该歌曲的许多艺术家。每个艺术家也负责创作许多其他歌曲。因此，为了正确表示数据，您必须使用联结表，就像在第二个版本中一样。
答案 1 :(得分：2)
这取决于。如果您可以保证特定歌曲始终属于单个专辑，请选择第一种方法。如果没有，你有一个n对n的关系，需要一个连接表：这是你的第二种方法。两者在标准化方面都完全没问题。
以您可以将数据映射到数据库的方式设计数据库非常重要。
不要担心这里的表现。性能更多地取决于您如何优化索引以及查询的外观，而不是必须再执行一次连接操作（第二种方法，连接表，每次查询都需要多一次连接）。
答案 2 :(得分：1)
第一个结构是混合语义（例如，为每首单曲写下发布者名称）。第二种结构允许您将无效数据放入数据库中（例如，一首歌曲可以属于两张专辑）。以下是我从问题领域和我对设计的建议中理解的内容：
一张专辑仅由一位发布商发布，因此您无需在每首歌曲中指定发布者，只需要输入 相册表中的publisher_ID 。此外，如果您将 artist_ID 保留在歌曲表格中，则每首歌曲一次只能包含一位艺术家;但是通过将 song_ID 和 artist_ID 放在一个链接表中，您可以为一首歌创作多个艺术家（比如两位歌手一起唱一首歌的时间）。 publisher_id 会转到相册表，因为每个相册都是由一个发布商发布的。 同样对于表名，建议使用单数形式。
这是我建议的设计：
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 | ...
答案 3 :(得分：0)
歌曲可以出现在多个专辑中。想想最好的点击发布。重要的是缩小技术渣土并考虑应用程序（或数据库）的实际使用。
答案 4 :(得分：-3)
我坚持使用第一个，原因有两个：