所以我有一个带有表用户的数据库。 用户可以是主持人，所有者，也可以是两者中的任何一个，或两者兼而有之。
我可以将它设计为booleans isModerator和isOwner 这将成为db列
或者我可以创建一个列hasUserRight 主持人为1 2为所有者
使用它设计数据库的更好方法是什么？为什么？
答案 0 :(得分：2)
您显然在谈论用户角色，第二种选择是为每个角色使用标志。这将限制您到一定数量的角色，并且不容易理解。第一个选项没有规范化，添加功能会更多工作等。
添加包含角色和用户窗口表的表将为您提供更通用的解决方案。
答案 1 :(得分：1)
只要只有两个角色，您的解决方案都可以使用。但我同意其他人的观点，即每个角色的一栏更容易阅读，因此应该是首选。
但是，必须添加第三个角色时会出现问题。如果这是你确定永远不会发生的事情，那好吧。但如果可能发生，你应该考虑后果。让我们添加一个新角色＆＃34; revisor＆＃34;并且让我们说一个主管必须是主持人。
解决方案1：isModerator，isOwner
添加isRevisor。所有编写的代码将像以前一样运行。您可以为isRevisor添加代码。添加检查约束，以便在isModerator为false时不能将isRevisor设置为true。完成。
=＆GT;数据库（DDL）仅更改
解决方案2：hasUserRight 0 =无，1 =主持人，2 =所有者，3 =所有=主持人+所有者和约束 hasUserRight in（0,1,2,3）
（我不推荐这个，因为不同的值意味着什么并不明显。）
您需要更多价值观：4 =主持人+主持人，5 =全部=主持人+所有者+主持人（或更好3 =全部=主持人+所有者+主持人，5 =主持人+所有者？）。您的代码将被破坏，因为（1,3）中的hasUserRight不再选择所有版主。您将不得不修复代码。在（0,1,2,3,4,5）中将禁令更改为hasUserRight。
=＆GT;代码更改+数据库（DDL）更改
解决方案3：hasUserRight 0 =无，1 =主持人，2 =所有者，3 =全部=主持人+所有者以及表格UserRight，其中包含值0到3以及一个探索文本。 < / p>
同样，您需要更多值：4 =主持人+主持人，5 =全部=主持人+所有者+主持人（或更好3 =全部=主持人+所有者+主持人，5 =主持人+所有者？）。将它们添加到您的角色表中。您的代码将被破坏，因为（1,3）中的hasUserRight不再选择所有版主。您将不得不修复代码。无需改变任何约束;外键只允许有效值。
=＆GT;只有代码更改
解决方案4：表格角色和桥牌表user_role
只需在表格角色中插入新角色即可。如果您愿意，可以向表user_role添加条目。完成。你需要的只是插入。但是，您的dbms无法保证每个revisor都是主持人;你必须自己关心这个。
=＆GT;完全没有对代码或数据库（DDL）的更改
如您所见，解决方案2和3（hasUserRight）不好。决定解决方案1或4，无论您喜欢什么，并找到更合适的解决方案。
答案 2 :(得分：0)
您的第二个解决方案出现问题。如果用户是所有者和主持人怎么办？假设0既不代表所有者也不代表主持人，则必须为该情况分配第四个数值。即使这种布局有详细记录，它仍然不会是直观的。
您的第一个解决方案更清晰，更易于理解。