使用一个数字数据库列vs几个布尔列

-2

所以我有一个表用户的数据库。用户可以是主持人，所有者，或者两者都不是，或者两者都不是。使用一个数字数据库列vs几个布尔列

我可以给布尔isModerator和isOwner 这将成为DB列

或者我可以创建一个列hasUserRight 与1主持人 2所有者

什么是更好的方法设计本用它来设计数据库，为什么？

来源

2014-05-22 Toskan

“什么更好”显然是一种基于意见的答案的表示，不是吗？ – Gabe

只要有两个角色，您的解决方案就可以工作。但是我同意其他人的观点，即每个角色的一列会更容易阅读，因此应该是首选。

但是，当需要添加第三个角色时会出现问题。如果这是你肯定知道的东西永远不会发生，好吧。但如果可能发生，你应该考虑后果。让我们添加一个新的角色“revisor”，让我们说一个修改者必须是主持人。

解决方案1：isModerator，isOwner

添加isRevisor。所有书面代码将像以前一样运行。您可以添加isRevisor的代码。添加检查约束，以便isModerator为false时isRevisor不能设置为true。完成。

=>数据库（DDL）仅改变

解决方案2：hasUserRight 0 =无，1 =主持人，2 =所有者，3 =所有=主持人+所有者和约束 hasUserRight在（0,1 ，2,3）

（我不会推荐，因为它不是什么明显不同值的含义）

你需要更多的值：4 =主持人+反向器，5 =所有=主持人+所有者+更好（或更好3 =全部=主持人+所有者+修正者和5 =主持人+所有者？）。您的代码将被破坏，因为（1,3）中的hasUserRight不再选择所有版主。你将不得不修复代码。（0,1,2,3,4,5）将约束改为hasUserRight。

=>代码改变+数据库（DDL）改变

解决方案3：hasUserRight 0 =无，1 =主持人，2 =所有者，3 =所有=主持人+所有者和表UserRight保持值0到3和一个爆炸性的文字。

同样，你需要更多的价值：4 =调节者+修正者，5 =全部=主持人+所有者+修正者（或更好的3 =全部=主持人+所有者+修正者和5 =主持人+所有者？）。将它们添加到您的角色表中。您的代码将被破坏，因为（1,3）中的hasUserRight不再选择所有版主。你将不得不修复代码。不需要改变任何约束;外键只允许有效值。

=>只有代码改变

解决方案4：表角色和一个桥接表USER_ROLE

只需插入在表角色新角色。如果你愿意的话，添加条目到表user_role。完成。所有你需要的是插入。不过，您的dbms不能保证每个修改者都是主持人;你必须自己关心这个。

=>无改变在所有代码或数据库（DDL）

正如所看到的溶液2和3（hasUserRight）是坏的。决定解决方案1或4，无论你喜欢什么，找到更合适的解决方案。

来源

2014-05-22 10:56:47

您的第二个解决方案出现问题。如果用户是所有者和主持人，该怎么办？假设0既不是所有者也不是主持人，那么您必须为该情况分配第四个数值。即使这个布局有很好的文档记录，它仍然不会很直观。

您的第一个解决方案更简洁易懂。

来源

2014-05-22 03:43:22 CorbinMc

是的，绝对正确。 – Rahul

您明确地谈论用户角色，您的第二个选择是使用每个角色的标志。这会将您限制在一定数量的角色中，并且不易理解。第一个选项没有标准化，添加功能将会有更多的工作等。

添加一个包含角色和userrole表的表将为您提供更通用的解决方案。

来源

2014-05-22 05:23:41 Peter

使用一个数字数据库列vs几个布尔列

回答

相关问题