这是数据库设计还是授权/权限责任答案

【问题标题】：Is this database design or authorization / permissions responsibility这是数据库设计还是授权/权限责任
【发布时间】：2011-06-06 23:47:51
【问题描述】：

我正在考虑我的项目的权限系统，但我无法决定如何组织我的权限系统。简而言之，我会将我的问题描述为：
我应该创建共享实体（行）并应用权限还是为每个用户创建单独的实体（行）副本？

我的情况：我有 2 个实体

Company
{
   [PK]
   Id,
   Name, 
   Contacts, 
   OwnerUser
}, 
Contact
{
   [PK]
   Phone,
   ContactPerson
}

具有多对多关系。允许用户修改他们创建（拥有）的公司实体。

我的问题：联系人实体（行）可以在不同用户拥有的公司之间共享，并且假设两个用户都想将 Contact.ContactPerson 编辑为不同的值（例如，一个用户声称电话号码属于约翰，和其他它是汤姆的号码），如果我为每个公司（以及用户）创建单独的联系人副本，则可以解决这种情况，但是我的业务规则不允许具有相同电话号码的重复联系人，并且还有其他联系人属性除了电话号码之外，还必须共享（根据我的业务规则）。

如何解决这种情况？

【问题讨论】：

标签： c# database-design permissions business-logic

【解决方案1】：

最后，您必须创建一个策略。如果发生冲突（例如在版本控制中），您可以应用合并策略，或者只有联系人创建者可以编辑的严格策略，或者只要联系人在她的公司，任何人都可以编辑联系人，或者使用复杂的策略评级（点）以访问像stackoverflow这样的编辑：P。

而这个问题只能通过直接询问客户，他想应用什么样的政策来解决。

【讨论】：

【解决方案2】：

听起来您的业务逻辑在那里存在冲突。一方面，您说两个用户可能会就号码是谁的电话号码存在分歧（如果两个人共用一张桌子/电话，这是完全有效的）。另一方面，您说您的业务逻辑不允许重复的电话号码。

为什么你的逻辑坚持唯一的电话号码？在我看来，您创建的 PK 不能保证是唯一的，因此不合适。

【讨论】：

电话是唯一且共享的，因为它包含必须在拥有此电话号码的所有公司之间共享的属性。否则，当某些 Phone 属性发生变化时（假设某个 Flag），我们将不得不在 DB 中查找所有 Phone 实例并更新此 flag\property。
好的；在这种情况下，当您说应该将 ContactPerson 和电话号码分开时，您是对的-它们是独立的实体。但是，在这种情况下，您要求联系人不能有重复的电话号码是没有意义的，因为它将是将多个联系人链接到一个电话号码的外键。