更好的做法是：存储字符串或使用关系？

Question

好吧，我必须自己选择哪种方法更好。我试图解释我的意思。例如，我有表john：

Songs

而且，我想实现表Id | Name | Artist | Year ---+------+--------+------- 1 | Ad | Bad | 2015 2 | Sad | ads | 2011 3 | Wad | Had | 2012 。而且我不完全知道，哪种做法会更好。

方法1-使用字符串存储歌曲ID

Playlists表：

Playlists

因此，要获取某些播放列表存储的歌曲，每次从DB生成列表时，我都会对其进行解析。

方法2-使用多对多关系策略

Id | Name | Songs ---+------+------------------------ 1 | Main | 1,2 2 | GYM | 4,6,7,8,53,65,76878,78, 3 | Rock | 121,434,655,6767,78 表：

Playlists

Id | Name ---+------ 1 | Main 2 | GYM 3 | Rock 表：

PlaylistSongs

方法3-您的建议

如果您知道更好的做法，请随时与我分享：）

感谢关注！

Answer 1

这个评论太长了。

PlaylistSongs –多对多关系–是存储数据的正确方法。原因如下：

• SQL表中的列应包含一个值，而不是多个值。
• 歌曲在不同的播放列表之间共享。他们是他们自己的实体。您还需要有关每首歌曲的其他信息（例如，发行时间，流派等）。
• 数字不应该作为字符串存储在关系数据库中；它们应该存储为某种数字类型。
• 应该在表之间正确声明外键关系。
• SQL通常具有很差的字符串解析功能。
• SQL可以优化以正确格式存储的数据。

Answer 2

当然，在这种情况下，播放列表表显然没有原子值而是具有与PlaylistId相同列的簇，因此需要多对多关系。通常，这是我们遇到数据冗余/重复/原子性的最佳实践（在这种情况下，经验法则可应用任何规范化（拆分表））。数据完整性约束为ACID（原子性，一致性，隔离性，耐久性）

Answer 3

按照方法2中的解释，您肯定会创建一对多关系场景，方法是创建一个PlaylistSongs表。这确实适合作为RDBMS中的关系数据库方案。在以下情况下，请考虑与第一种方法相比所获得的收益。

1。）数据一致性问题，例如，如何从专辑所附的“歌曲”表中删除歌曲。第一种方法不会限制您这样做，但是在第二种方法中，您可以创建会触发错误的外键关系。

2。）数据联接。例如，使用SQL可以使用Join来获取给定专辑中所有可用的歌曲，但是在第一种方法中，您首先必须首先进行手动字符串操作以提取ID，然后再单独获取歌曲记录（对于在计算机上编程和忙碌

3。）最终，您具有完整的SQL支持，可以查询多种情况进行报告，例如，使用Count获取给定专辑中的歌曲数量等。

谢谢。