Как уже упоминалось Мартином Смитом и Микаэлем Эрикссоном, сделать это свойство объекта очень аккуратным и понятным подходом.Чисто с точки зрения представления данных, это очень приятно.
Я бы, однако, также рассмотрел запросы, которые вы, вероятно, сделаете к данным.Например, основываясь на вашем описании, вы, скорее всего, имеете запросы, которые начинаются с одного пользователя, находят группы, членами которых они являются, а затем находят сущности, с которыми они связаны.Возможно, что-то вроде этого ...
SELECT DISTINCT -- If both user and entity relate to multiple groups, de-dupe them
entity.*
FROM
user
INNER JOIN
user_link_group
ON user.id = user_link_group.user_id
INNER JOIN
group_link_entity
ON group_link_entity.group_id = user_link_group.group_id
INNER JOIN
entity
ON entity.id = group_link_entity.entity_id
WHERE
user.id = @user_id
Если бы вы использовали этот формат и идею свойства в таблице сущностей, вам потребовалось бы нечто гораздо менее элегантное, и я думаю, что следующий подход UNIONвозможно, наиболее эффективен ...
<ORIGINAL QUERY>
UNION -- Not UNION ALL, as the next query may duplicate results from above
SELECT
entity.*
FROM
entity
WHERE
EXISTS (SELECT * FROM user_link_group WHERE user_id = @user_id)
AND isVisibleToAllGroups != 0
-- NOTE: This also implies the need for an additional index on [isVisibleToAllGroups]
Вместо создания углового регистра в запросе "какой объект можно увидеть", вместо этого можно создать угловой регистр при ведении ссылкитаблицы ...
- Создание группы GLOBAL
- Если элемент виден всем группам, сопоставьте их с группой GLOBAL
- Если пользователь добавлен вгруппа, убедитесь, что они также связаны с группой GLOBAL
- Если пользователь удален из всех групп, убедитесь, что они также удалены из группы GLOBAL
Таким образом,Оригинальный простой запрос работает без изменений.Это означает, что никакой UNION не требуется, с его накладными расходами на сортировку и дедупликацию, и не требуется ни INDEX для isVisibleToAllGroups.Вместо этого накладные расходы переносятся на поддержание того, с какими группами связан пользователь;вместо этого один раз.
Это предполагает, что вопрос "какие объекты я могу видеть" более распространен, чем изменение групп.Это также добавляет поведение, которое определяется DATA, а не SCHEMA, что требует хорошей документации и понимания.Таким образом, я рассматриваю это как мощный тип оптимизации, но я также вижу его как компромиссный вариант, который необходимо учитывать при проектировании базы данных.