Выборки с учетом приватности

[Koc]

Есть мероприятия. Они привязаны к нескольким районам. Могут быть приватными - тогда их видит определенный круг лиц, приглашенных на эти мероприятия. Могут состоять в группе. Группы в свою очередь тоже могут быть открытыми и закрытыми. А также возможны комбинации - закрытое мероприятие в закрытой группе.

Выборки сейчас идут через MySQL и выглядят довольно кисло. Что-то типа

SELECT
  e
FROM event e
  LEFT JOIN e.invitee i WITH i.user = :current_user
  LEFT JOIN e.group g
  LEFT JOIN g.participants p WITH g.user = :current_user
WHERE ((e.is_private = false AND e.group IS NULL) OR  (e.is_private = true AND i IS NOT NULL) OR (e.group IS NOT NULL AND g.is_open) /* ... */) AND /* прочие фильтры, например по районам */

Вопрос: как и в чем это нужно хранить, что б обеспечить нормальную скорость доступа к данным с учетом приватности?

 

[Redjik]

Дак может классический RBAC сделать?

 

[Ragazzo]

Redjik
Заебешься делать через RBAC, если надо добавлять/удалять доступ отдельно к объектам, не плодить же кучу ролей, тут будет что-то типа ACL + RBAC(для групп) )) Было нечто похожее (куча условий доступа, группы и т п), но обошлись как-то ловко двумя таблицами, в одной правила доступа к объектам в другой названия всех правил или объектов.

 

[Redjik]

Ragazzo
Дак вариации - не имеют значения - одна строчка в таблице с приватностью - намного больше гемора, я и имел ввиду групповые права сделать на основе RBAC, если денек посидеть, то можно очень неплохо сделать - имхо.

 

[Ragazzo]

Redjik
Не, погоди, тут насколько я понял схема такая: права можно назначать непосредственно напрямую ACL и также распространяются права если состоит в группе, т.е. если ты только через RBAC будешь делать то надо будет перебрать кучу вариаций комбинаций, вместо того чтобы использовать иерархию ACL > RBAC. А может я что-то попутал в вопросе.

 

[Koc]

Дак может классический RBAC сделать?

1. я не думаю, что оно улучшит производительность.
2. какие роли вводить? на каждое закрытое мероприятие по роли?

 

[scb]

Не проще все это вытянуть в отдельную таблицу?

 

[Koc]

можно, да. А как ее наполнять? Как-то асинхронно, но все равно это будет затратно. Подключился пользователь в группу - ему нужно сразу туда внести все ее мероприятия.

 

[Ragazzo]

Koc
Надо не пользователю внести мероприятия, а пользователя в группу внести всего лишь.

 

[Koc]

Koc
Надо не пользователю внести мероприятия, а пользователя в группу внести всего лишь.

и как тогда выборка будет выглядеть?

 

[Ragazzo]

и как тогда выборка будет выглядеть?

В лучшем случае будет 1 запрос, в худшем 2, т.е. сначала проверяешь есть ли у пользователя прямое право доступа к тому или иному объекту, если есть то ок, а если нету то проверяешь есть ли у группы в которой состоит пользователь права на этот объект, и если что возвращаешь значение этого права. Структура таблица как ты мог понять похожая, поменялись лишь сами объекты, т.е в первом случае манипулировали правом пользователя на объект, а во втором правом группы на объект (грубо говоря в первом случае user_id в таблице прав, во втором group_id).

 

[Koc]

погоди, мне это нужно не для просмотра конкретного объекта а для списочных страниц с пагинацией и сортировками. Какие 2 запроса?

 

[Ragazzo]

Koc
Ну дак та же самая задача, тебе нужно вывести список чего-либо взависимости от уровня доступа к тому что ты выводишь, так? Т.е. ты выводишь какой-либо тип "объект доступа" вот и все.

 

[Koc]

event
id, title, group (nullable), is_private

event_invitee
event_id, user_id

group
id, title, is_open

group_participant
group_id, user_id

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

 

[Ragazzo]

Если такая схема то нужно еще добавить одну таблицу для соотношения групп и пользователей т.е. users_groups_relations например, банально user_id, group_id, и таблицу для ивентов для группы, аналогично той что у тебя для пользователей, т.е. event_invitee_group. Ну и дальше делай согласно твоей схеме селект для простого юзера и юнионом для селекта группы, в которой присутствует данный пользователь.
P.S. тут описал скорректированно для твоей схемы таблиц, изначально думал по-другому сделать.

 

[WMix]

в event_invitee нужно хранить и user_id и group_id или иметь 2 таблицы, одна приглашения, только для пользователей, другая приглашенные группы
те приглашены группы а также кучка людей!...
какой эвент ? приглашены DISTINCT все пользователи групп group_id а также все user_id!

 

[Ragazzo]

WMix
Хватит заниматься бампингом.

 

[WMix]

для соотношения групп и пользователей т.е. users_groups_relations

у него это завется group_participant

Бампинг (от англ. bump — удар, толчок, столкновение) — метод вскрытия замков, основанный на передаче кинетической энергии штифтам вследствие ударов по специально выточенному ключу.

не понимаю....

 

[Ragazzo]

WMix
пост бампинг. ты за день по штук 20 сообщений фигачишь сомнительного качества.

 

[WMix]

сижу читаю форум, все что не прочтенное, есть интересное, там отвечаю, коммуницирую так сказать.. а на счет "сомнительного" даж не знаю что сказать, мнение у меня такое....