Является ли это дизайном базы данных или авторизацией/разрешениями?

Я думаю о системе разрешений для своего проекта и не могу решить, как организовать свою систему разрешений. В краткой абстрактной форме я бы описал свой вопрос так:
Должен ли я создавать общие сущности (строки) и применять разрешения или создавать отдельные копии сущности (строки) для каждого пользователя?

Моя ситуация: у меня есть 2 объекта

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

которые имеют отношение многие ко многим. Пользователям разрешено изменять сущность Компании, которую они создали (свою).

Моя проблема: объект контакта (строка) может быть разделен между компаниями, которые принадлежат разным пользователям, и предположим, что оба пользователя хотят отредактировать Contact.ContactPerson на другое значение (например, один пользователь утверждает, что номер телефона принадлежит Джону, а другой, что это номер Тома), эту ситуацию можно решить, если я создам отдельную копию Контакта для каждой Компании (и, следовательно, пользователя), но мои бизнес-правила не позволяют дублировать Контакты с одним и тем же номером телефона, и есть другие свойства Контакта, которые должны быть общими. (согласно моим бизнес-правилам) помимо номера телефона.

Как решить эту ситуацию?


c# permissions database-design business-logic
person Alex Burtsev    schedule 11.01.2011    source источник

Ответы (2)


arrow_upward
1
arrow_downward

В конце вы должны создать политику. вы можете применить политику для слияния, если возник конфликт (например, в контроле версий), или строгую политику, которую может редактировать только создатель контакта, или любой может редактировать контакт, пока контакт находится в ее компании, или сложную политику, которая использует рейтинг (балл), чтобы получить доступ к редактированию, например stackoverflow: P.

и эту проблему можно решить, только спросив непосредственно у клиента, какую политику он хочет применить.

person ikhsan    schedule 12.01.2011

arrow_upward
0
arrow_downward

Похоже, ваша бизнес-логика находится в конфликте. С одной стороны, вы говорите, что два пользователя могут не согласиться с тем, чей номер телефона является номером (что совершенно справедливо, если два человека делят стол/телефон). С другой стороны, вы говорите, что ваша бизнес-логика не допускает дублирования телефонных номеров.

Почему ваша логика настаивает на уникальных телефонных номерах? Мне кажется, что вы создали ПК, который не обязательно будет уникальным и поэтому неподходящим.

person kander    schedule 11.01.2011
comment
Телефон уникален и является общим, поскольку он содержит свойства, которые должны быть общими для всех Компаний, у которых есть этот номер телефона. В противном случае при изменении какого-либо свойства телефона (допустим, какого-либо флага) нам придется найти все экземпляры телефона в БД и обновить этот флаг\свойство. - person Alex Burtsev; 11.01.2011
comment
Хорошо; в этом случае вы правы, когда говорите, что вам следует разделить ContactPerson и номер телефона - это разные сущности. Однако ваше требование о том, что контакты не могут иметь повторяющиеся номера телефонов, в этом случае не имеет смысла, поскольку это будет внешний ключ, связывающий несколько контактов с одним номером телефона. - person kander; 11.01.2011