数据库设计。一对多还是多对多？ [关闭]答案

【问题标题】：Database design. One-to-many or Many-to-many? [closed]数据库设计。一对多还是多对多？ [关闭]
【发布时间】：2016-01-11 20:43:49
【问题描述】：

在我的应用程序中，我需要为我的用户分配多个组。有 1000 多个用户和 10-15 个组。

哪个数据库设计更好？

一对多：

USER_ID | GROUP_1 | GROUP_2 | ... | GROUP_15
--------------------------------------------
 1      | true    | false   | ... | true
 2      | false   | true    | ... | true
 3      | true    | true    | ... | true
 .      | .       | .       | ... | . 
 .      | .       | .       | ... | . 
 .      | .       | .       | ... | .

或多对多：

USER_ID | GROUP_ID 
------------------
 1      | 1
 1      | 15
 2      | 2
 2      | 15
 3      | 1
 3      | 2
 3      | 15
 .      | .       
 .      | .       
 .      | .

【问题讨论】：

第一个不是任何传统意义上的“一对多”，第二个是你应该使用的设计。
This post 可能对你有用。
尝试编辑这个问题，并以鼓励具体答案而不是一般意见的方式重新表述它。一般来说，数据库的设计应该是特定于业务的。通常会有多种同样可以接受的解决方案。

标签： mysql sql database sqlite relational-database

【解决方案1】：

毫无疑问，多对多是更好的设计。

第一个设计使编写查询变得困难。考虑以下例行查询。

指定的用户是否在指定的组中？为此，您必须对每个组使用不同的查询。这是不可取的。此外，如果您为组使用列名，则组列表是数据库架构的一部分，而不是数据的一部分，其中用户是数据。
指定用户属于哪些组？您可以简单地返回单行，尽管许多应用程序可能更喜欢（并且精通）遍历结果集。遍历列的子集是可行的，但不自然。
指定组包含哪些用户？现在您回到每个组的不同查询.. 我将把这些东西的演示留给读者作为练习。 SQL 数据库近似的关系模型旨在处理关系和键（表和主/外键）。信息应该作为数据（而不是元数据）存在于一个（并且只有一个）位置。多列方法缺乏规范化，未来将是一个令人头疼的维护问题。

注意：我编辑了此回复以纠正我对原始代码部分的误读。然而，cmets 的推力是相同的。第二个（多对多）是要走的路。

【讨论】：

【解决方案2】：

没有2是标准的，你可以随时增加组的数量，也可以轻松处理简单的sql连接查询。

【讨论】：

【解决方案3】：

如果要遵循实体关系模型的规则：

Many-to-many: users can belong to different groups & groups can have multiple users.

One-to-many: a user belongs to one group & groups can have multiple users.

您的第二个示例是多对多，您的第一个示例不是一对多。一对多是：

USER_ID | GROUP_ID 
------------------
 1      | 1
 2      | 15
 3      | 2
 4      | 15
 5      | 1
 6      | 2
 7      | 15

其中 user_id 必须是唯一的。

【讨论】：

抱歉。我的第一个例子有具体的名字吗？
不是真的，您的第一个示例只是一个表格，尚未（尚未）标准化。