сложная настройка user_roles многие ко многим

Question

Я пишу базу данных бэкэнд-опросов. База данных является бэкендом для нескольких приложений, которые используются для сбора данных типа опроса. У меня есть схема, которая включает таблицу, которая обозначает приложение и какие вопросы относятся к этому приложению.

Теперь мне нужно настроить пользователей и роли пользователя ...

каждый пользователь может иметь доступ к 1 или более приложениям каждое приложение имеет 1 или более пользователей

каждый пользователь может иметь 1 роль в приложении, к которому у него есть доступ каждая роль может существовать в 1 или более приложениях у каждого пользователя могут быть разные роли в каждом приложении.

приложение 1 имеет 15 пользователей 1 пользователь является администратором app1 имеет 2 роли, определенные для доступа пользователя

app2 имеет 30 пользователей. Администратор. Пользователь app1 имеет доступ, но является обычным пользователем. 2 пользователя admin в app2 существуют в app1 как обычные пользователи Приложение 2 имеет 4 роли, определенные для доступа пользователя.

ПРЕДУПРЕЖДЕНИЕ БЕСПЛАТНОЙ ФОРМЫ МЫСЛЬНОГО ПРОЦЕССА

так что у меня

Приложение -> ApplicationUsers <-Users </p>

может быть, мне нужен только один присоединяемый стол, тогда вот так?

Это было бы правильно? Будет ли это работать в EF 4.0?

Как правильно сделать эту работу?

Answer 1

Я думаю, что может быть несколько разных способов реализации отношений, и самый важный фактор для определения наилучшего способа - это то, как вы собираетесь использовать данные. Это может быть сделано с четырьмя таблицами, как вы описываете, я предпочитаю единственное число, а не множественное число для всех таблиц - вплоть до отдельных, но вы должны быть последовательными и применять его, если другие таблицы множественного числа. Поскольку отношения определяются всеми тремя объектами, это должна быть структура таблицы. Тем не менее, вопрос, который нужно задать, состоит в правильности этих отношений? Я думаю, что очевидно, что приложение может существовать независимо от того, есть ли у него пользователи или нет, как можно было бы сказать о пользователе, независимо от того, связано ли оно в настоящее время с приложением. Однако существует ли роль, если она не связана с приложением? Вероятно, не роль (хотя она может иметь одно и то же имя) может быть не совсем эквивалентной в каждом приложении.

Другим вариантом, может быть, более понятным (лучше?) Логически, было бы иметь таблицу Role (AppRole?) С Application FK в ней и таблицу UserAppRole, которая связывает пользователей с ней. Это позволит вам определить роль относительно приложения, к которому он применяется, и связать пользователя с приложением (ями) через соответствующие роли.

Применение AppRole пользователь UserAppRole

Как я уже сказал, множество способов сделать это и множество определяющих факторов.

Answer 2

Предположим, что этот

каждый пользователь может иметь 1 роль в приложении, к которому у них есть доступ к каждой роли, может существовать в 1 или более приложениях, каждый пользователь может иметь разные роли в каждом приложении.

следует акцентировать следующим образом.

Каждый пользователь может иметь 1 роль в приложении, к которому он имеет доступ, каждая роль может существовать в 1 или более приложениях, каждый пользователь может иметьразличные роли в каждом приложении.

Если это первое предложение означает, что каждый пользователь должен иметь одну и не более одной роли в каждом приложении, к которому он имеет доступ, тогда ваша схема выигралане работаетСоставной первичный ключ {ApplicationId, UserID, RoleID} в ApplicationUserRoles позволяет использовать несколько ролей для каждого пользователя.

Чтобы ограничить ограничение «одна строка (и одна роль) на пользователя на приложение», первичный ключ для ApplicationUserRoles должен быть просто {ApplicationID, UserID}.

Кроме того, если UserID уникаленв таблице Users, вероятно, это должен быть первичный ключ, и вам следует удалить столбец «ID» из этой таблицы.