这是数据库设计还是授权/权限责任
我正在考虑我的项目的权限系统，但无法决定如何组织我的权限系统。简而言之，我将我的问题描述为：
我应该创建共享实体（行）并应用权限还是为每个用户创建单独的实体（行）副本？
我的情况：我有两个
Company
{
[PK]
Id,
Name,
Contacts,
OwnerUser
},
Contact
{
[PK]
Phone,
ContactPerson
}
具有多对多关系的实体。用户可以修改他们创建（拥有）的公司实体。
我的问题：联系人实体（行）可以在不同用户拥有的公司之间共享，并且假设两个用户都想将 Contact.ContactPerson 编辑为不同的值（例如，一个用户声称电话号码属于 John，而其他用户则声称该号码属于 John）这是汤姆的号码），如果我为每个公司（以及用户）创建单独的联系人副本，则可以解决这种情况，但我的业务规则不允许具有相同电话号码的重复联系人，并且必须共享其他联系人属性（根据我的业务规则）除了电话号码。
这种情况该如何解决呢？
I'm thinking about permissions system for my project and I can't make a decision on how to organize my permissions system. In short abstract form I would describe my question as :
Should I create shared entities (rows) and apply permissions or create separate entity (row) copy for each user?
My situation: I have 2 entities
Company
{
[PK]
Id,
Name,
Contacts,
OwnerUser
},
Contact
{
[PK]
Phone,
ContactPerson
}
which have many-to-many relationship. Users are allowed to modify Company entity which they created (own).
My problem: Contact entity(row) can be shared between Companies which are owned by different users, and suppose both users want to edit Contact.ContactPerson to different value (for example one user claims that than phone number belongs to John, and other that it's Tom's number), this situation can be resolved if I create separate copy of Contact for each Company (and therefore user), but my business rules doesn't allow duplicate Contacts with same phone number, and there other Contact properties that must be shared (according to my business rules) besides phone number.
How to resolve this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
最后您必须制定一项政策。如果发生冲突，您可以应用一个策略来合并（例如在版本控制中），或者一个严格的策略，只有联系人的创建者可以编辑，或者任何人都可以编辑联系人，只要该联系人在她的公司，或者使用复杂的策略评级（点）以获得编辑权限，如 stackoverflow :P。
而这个问题只能通过直接询问客户他想要应用什么政策来解决。
In the end you must create a policy. you can apply a policy to merging if conflict occurred (like in version control), or a strict policy that only creator of contact that can edit, or anyone can edit contact as long as the contact is in her company, or complex policy that using rating (point) to get access to edit like stackoverflow :P.
and this problems only can be solved with asking directly to the client, what a policy that he want to apply.
听起来您的业务逻辑在那里发生冲突。一方面，您说两个用户可能对某个号码是谁的电话号码存在分歧（如果两个人共用一张桌子/电话，这是完全有效的）。另一方面，您说您的业务逻辑不允许重复的电话号码。
为什么您的逻辑坚持使用唯一的电话号码？在我看来，你创建的 PK 不能保证是唯一的，因此不合适。
It sounds like your business logic is in conflict there. At one hand you're saying that it's possible for two users to disagree over who's telephone number a number is (which is perfectly valid, if two people share a desk/phone). On the other hand you say that your business logic doesn't allow duplicate phone numbers.
Why does your logic insist on unique phone numbers? It sounds to me like you've created a PK that is not guaranteed to be unique, and therefor unsuitable.