根据我的经验，如果你不想每次需要在应用程序中更新新权限时都添加额外的列。然后选择第二个选项。
优点：选项1：组没有冗余数据，并且可以轻松管理，因为您可以对组名应用唯一约束，因此不需要每次都插入。
选项2：您不需要添加alter-the表，只需验证新权限是否已存在，如果不存在，则只需添加新的insert或更新现有权限。
缺点：选项1：每当有新的权限出现时，您都需要更改表。
选项2：每当您想为一个组添加新的权限时，首先必须确定记录是否已经存在，然后必须插入到表中。同时，与第一个选项相比，验证的过程也有点复杂。
所以，两者各有利弊。如果你从数据冗余的Angular 考虑，那么选择选项1，否则选择选项2。
据我所知，我更愿意使用选项1，我将要做的只是维护一个额外的表，该表标识它们之间的权限和物理列，并且我将使其成为通用的。
好吧！！！

我建议你选第二张，因为正如你的老师所说，你不需要改变table。更改表意味着为表中的每个成员添加一个新的1或0（可以使用默认值，但仍需要更改需要特权的用户的值）。
就像你的老师说的那样，你可以拥有另一个拥有所有特权的表，并使用外键。
这样，您就可以添加一个新的权限，并将其分配给他们需要的用户，默认值为“1”，如果您需要撤销该权限，请将其更改为“0”。默认情况下，不会添加不必要的行，这在小表中不是问题，但在大表中是问题。

id  |user_id   |privilege   |active
1      1        can_do_this    1
2      1        can_do_that    1
3      2        can_do_this    1
4      2        can_do_that    0

对我来说，这是一个非常简单的数据建模问题。数据模型中有两个“实体”：
用户
特权
这意味着每个人都应该有自己的table。
因为这是一个多对多关系（许多用户可以拥有给定的特权，一个用户可以拥有许多特权），第三个表通常用于表示关系；这通常称为“连接表”或“关联表”。
您的教授给出了一个很好的理由来表示行而不是列中的值：添加新特权的能力。
我可以再补充几点：
这个 userPrivileges table可以有一个 createdOn 列，以便您知道特权何时生效。
这个 userPrivileges 我能喝一杯吗 createdBy 列，所以你知道谁授予了特权。
这个 userPrivileges table可以有一个 suspended 列，以便可以临时挂起特权。