Какова оптимальная структура БД для этого типа данных

Question

У меня есть таблица Users,

Каждый USR_ID может иметь несколько ролей, представлений, брендов и юнитов.

Итак, оптимальный дизайн, о котором я думал, это:

Users
USR_ID    USR_Username    USR_Password

Matrix
M_ID    M_USR_ID    M_ROLE_ID    M_VIEW_ID    M_BRAND_ID    M_UNIT_ID

_ROLES
ROLE_ID    ROLE_Name    ROLE_Active

_VIEWS
VIEW_ID    VIEW_Name    VIEW_Active

_BRANDS
BRAND_ID    BRAND_Name    BRAND_Active

_UNITS
UNIT_ID    UNIT_Name    UNIT_Active

Таким образом, в основном в таблице Matrix я храню все данные о том, кто чем занимается.

Мой вопрос такой: оптимальная структура и дизайн?Кроме того, как будут выглядеть строки в таблице Matrix?Это пример того, кто имеет ROLE_ID = 1

Matrix
1    30    1    4    7    2    4

Теперь, когда я хочу добавить еще одну РОЛЬ этому человеку, как будет выглядеть следующая строка?Сохраняю ли я значения всех других определений (бренд, единица, вид ...)?Или я просто вставляю все с NULL, кроме ROLE_ID?

Ваша помощь очень ценится,

Спасибо,

Answer 1

Я бы не использовал вашу матричную таблицу.Вместо этого используйте таблицы перекрестных ссылок.

Чтобы связать пользователей и роли:

User_Roles
USR_ID    ROLE_ID

Создайте таблицу ссылок для каждой таблицы: роли, представления, бренды, единицы.Таким образом, вы можете иметь несколько юнитов, например, для пользователя без привязки каждого к определенной роли.И вы можете иметь три подразделения, три роли и три бренда без создания 27 матричных записей.

Answer 2

(начало ответа удалено, потому что Скотт сказал это на минуту быстрее и яснее, чем я.)

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

Что не ясно из вашего вопроса, есть ли какая-либо зависимость между ролями / представлениями / брендами и единицами.Стоит следить за этим при разработке таблицы - для глупого примера с вашими данными: если пользователю с данным брендом всегда нужны одинаковые единицы, и нет других причин, по которым у пользователей есть единицы, то вам не нужныподключать блоки к пользователям вообще, только к брендам.Но это уточнение.

Отправной точкой, безусловно, должен быть проект, предложенный Скоттом: по одной таблице для пользователей, ролей, представлений, брендов, единиц и четырех таблиц перекрестных ссылок, связывающих пользователей с четырьмя другими.