在这种特定情况下，使用一对多关系比再添加 1 列有什么优势？
What is the advantage of using 1 to many relationship over adding 1 more column in this particular situation?
这是一对多关系的典型情况：一个聊天群iOS应用程序，一个群table记录所有群聊相关信息，如群id，创建时间，线程标题等
为了记录参与者，当然，我会假设还有另一个1:m table。所以我很惊讶地看到该应用程序刚刚添加了另一个名为 "participants" 的列来记录它，每个参与者都用分隔符（准确地说是“:”）分隔。这样做的问题非常明显，将应用程序代码与 sql 代码混合在一起，例如无法通过 sql 代码、违反 1NF/2NF 等方式查看特定用户在多少个组中
但是他们说我们理解你的所有观点。但是
- 因为这是一个移动应用程序，您总是需要使用 objective c 代码来访问 sqlite tables，您不会单独使用 sql 代码.所以不是 "big deal" 将它们混合在一起。
- 参与者不会经常更改，通常在创建群组时设置。如果我们有 100 名参与者，我们宁愿只将 1 条记录插入到组 table 而不是将 100 条记录插入到另一个 group-participants table.
参与者数据将在有人想查看此聊天组中的成员（通过多次点击菜单）以及有人加入或离开聊天组时使用，假设这种情况不会经常发生。
所以我的问题是在这种特殊情况下，如果我使用另一个 1:m table，我将获得什么优势？
-----更新-----
除了我得到的答案，Renzo kindly pointed this discussion对我来说，也很有帮助！
在不了解完整上下文的情况下很难回答 "is this design better/worse" 风格的问题。我将根据你的问题做出一些假设。
您似乎正在构建一个支持 "many to many" 用户聊天的移动应用程序。我在想象像 Slack 这样的东西。
您的应用程序设计使用 SQLite 数据库进行本地存储。
您在 phone 上的本地 sqlite 数据库是整个应用程序数据的某种子集 - 就像一个缓存，只显示当前用户的数据。
如果这一切都是真的，那么问题实际上是一方面 style/maintainability，另一方面是性能和可扩展性。
从 "style" 的角度来看，将数据存储在列中的逗号分隔值中是丑陋的。加入该项目且具有 "regular" 数据库设计背景的新开发人员最多会将其视为 hack。另一方面，iOS 开发人员可能认为这是完全正常的。
从性能的角度来看，这可能不值得争论 - 解析 CSV 可能与从数据库解析 reading/writing 一样慢。
从可扩展性的角度来看，您可能遇到了问题。如果应用程序设计需要捕获用户加入聊天的顺序，或捕获某种状态（例如 active/asleep），或提供一些历史记录（用户 x 在 21:20 退出），您几乎肯定最终会重新设计数据库。
这是一对多关系的典型情况：一个聊天群iOS应用程序，一个群table记录所有群聊相关信息，如群id，创建时间，线程标题等
为了记录参与者，当然，我会假设还有另一个1:m table。所以我很惊讶地看到该应用程序刚刚添加了另一个名为 "participants" 的列来记录它，每个参与者都用分隔符（准确地说是“:”）分隔。这样做的问题非常明显，将应用程序代码与 sql 代码混合在一起，例如无法通过 sql 代码、违反 1NF/2NF 等方式查看特定用户在多少个组中
但是他们说我们理解你的所有观点。但是
- 因为这是一个移动应用程序，您总是需要使用 objective c 代码来访问 sqlite tables，您不会单独使用 sql 代码.所以不是 "big deal" 将它们混合在一起。
- 参与者不会经常更改，通常在创建群组时设置。如果我们有 100 名参与者，我们宁愿只将 1 条记录插入到组 table 而不是将 100 条记录插入到另一个 group-participants table.
参与者数据将在有人想查看此聊天组中的成员（通过多次点击菜单）以及有人加入或离开聊天组时使用，假设这种情况不会经常发生。
所以我的问题是在这种特殊情况下，如果我使用另一个 1:m table，我将获得什么优势？
-----更新-----
除了我得到的答案，Renzo kindly pointed this discussion对我来说，也很有帮助！
在不了解完整上下文的情况下很难回答 "is this design better/worse" 风格的问题。我将根据你的问题做出一些假设。
您似乎正在构建一个支持 "many to many" 用户聊天的移动应用程序。我在想象像 Slack 这样的东西。
您的应用程序设计使用 SQLite 数据库进行本地存储。
您在 phone 上的本地 sqlite 数据库是整个应用程序数据的某种子集 - 就像一个缓存，只显示当前用户的数据。
如果这一切都是真的，那么问题实际上是一方面 style/maintainability，另一方面是性能和可扩展性。
从 "style" 的角度来看，将数据存储在列中的逗号分隔值中是丑陋的。加入该项目且具有 "regular" 数据库设计背景的新开发人员最多会将其视为 hack。另一方面，iOS 开发人员可能认为这是完全正常的。
从性能的角度来看，这可能不值得争论 - 解析 CSV 可能与从数据库解析 reading/writing 一样慢。
从可扩展性的角度来看，您可能遇到了问题。如果应用程序设计需要捕获用户加入聊天的顺序，或捕获某种状态（例如 active/asleep），或提供一些历史记录（用户 x 在 21:20 退出），您几乎肯定最终会重新设计数据库。