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

【问题标题】：What is better practice: to store a string or use relations?什么是更好的做法：存储字符串或使用关系？
【发布时间】：2019-01-01 16:45:43
【问题描述】：

好吧，我必须自己选择哪种做法更适合使用。我试图解释我的意思。比如我有表Songs:

Id | Name | Artist | Year
---+------+--------+-------
1  | Ad   | Bad    | 2015
2  | Sad  | ads    | 2011
3  | Wad  | Had    | 2012

另外，我想实现表Playlists。而且我不完全知道，哪种做法会更好。

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

Playlists表：

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

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

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

Playlists表：

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

PlaylistSongs表：

Id | PlaylistId | SongId
---+------------+---------
1  |      1     |    1
2  |      1     |    2    
4  |      1     |  344 
5  |      1     |   45
6  |      1     |   57

方法 #3 - 您的建议

如果你知道更好的做法，请随时与我分享:)

感谢关注！

【问题讨论】：

肯定使用多对多表，但它只需要有歌曲和播放列表 id 它不需要它自己的 id，除非你希望能够关联同一首歌同一个播放列表不止一次。
绝对是选项二。选项一更像是描述数据的文本。它不是关系数据。为了说明这一点，想象一下尝试编写查询来尝试搜索播放列表中的某些歌曲或将表连接在一起。选项 1 真的很难看，但选项 2 很容易。

标签： c# sql sql-server

【解决方案1】：

PlaylistSongs -- 多对多关系 -- 是存储数据的正确方式。以下是一些原因：

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

【讨论】：

【解决方案2】：

当然，作为播放列表所需的多对多关系显然没有原子值，而是在这种情况下与PlaylistId 具有相同列的集群。通常，这是我们遇到数据冗余/重复/原子性（在这种情况下应用任何规范化（拆分表）的拇指规则）的最佳实践。数据完整性约束为 ACID (ATOMICITY, CONSISTENCY, Isolation, Durability)

【讨论】：

【解决方案3】：

当然，您将通过创建 PlaylistSongs 表来实现您在方法 2 中解释的一对多关系场景。这真正适合作为 RDBMS 中的关系数据库场景。考虑一下在以下场景中与第一种方法相比您获得的好处。

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

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

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

谢谢。

【讨论】：