在这种特殊情况下，使用 1 对多关系比添加 1 列有什么优势？

Question

这是一对多关系的典型情况：一个聊天群 iOS 应用，一个群表，记录所有群聊相关信息，如群 id、创建时间、线程标题等。

当然，为了记录参与者，我假设还有另一个 1:m 表。所以我很惊讶地看到该应用程序刚刚添加了另一个名为“参与者”的列来记录它，每个参与者都用分隔符分隔（准确地说是“：”）。问题很明显，将应用程序代码与 sql 代码混合，例如无法通过sql代码查看特定用户在多少组中，违反了1NF / 2NF等。

但他们说我们理解你的所有观点。但是

1. 因为这是一个移动应用程序，你总是需要使用客观的c代码来访问sqlite表，你不会单独使用sql代码。因此，将它们混合在一起并不是什么“大事”。
2. 参与者不会经常更改，通常在创建组时设置。如果我们有 100 个参与者，我们宁愿只将 1 条记录插入到组表中，而不是将 100 条记录插入到另一个组参与者表中。

当有人想查看谁在这个聊天组中（通过在菜单上点击几下）以及当有人加入或离开聊天组时，将使用参与者数据，假设它不会经常发生。

所以我的问题是，在这种特殊情况下，如果我使用另一个 1:m 表，我将获得什么优势？

-----更新-----

除了我得到的答案，Renzo 好心把这个discussion 指给我，这也很有帮助！

Answer 1

如果不了解完整的上下文，很难回答“这种设计更好/更差”的风格问题。我将根据您的问题做出一些假设。

您似乎正在构建一个移动应用程序，支持“多对多”用户聊天。我在想象 Slack 之类的东西。

您的应用程序设计使用 SQLite 数据库进行本地存储。

您手机上的本地 sqlite 数据库是整个应用程序数据的某种子集 - 就像缓存一样，只显示当前用户的数据。

如果这一切都是真的，那么问题确实一方面在于样式/可维护性，另一方面在于性能和可扩展性。

从“样式”的角度来看，将数据以逗号分隔的值存储在列中是很难看的。加入该项目的具有“常规”数据库设计背景的新开发人员最多会认为它是一个 hack。另一方面，iOS 开发者可能会认为这完全正常。

从性能的角度来看，这可能不值得争论 - 解析 CSV 可能与从数据库读取/写入一样慢。

从可扩展性的角度来看，您可能会遇到问题。如果应用程序设计需要捕捉用户加入聊天的顺序，或捕捉某种状态（例如活动/睡眠），或提供一些历史记录（用户 x 在 21:20 退出），你几乎可以肯定结束重新设计数据库。