Блокировка страниц при совместном редактировании

Question

[pyatin]

Доброго времени суток.

Есть такая структура базы данных



Краткое описание:

users — таблица пользователей.

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

wedding — таблица свадеб.

user_edit_rights — Права пользователя в конкретной свадьбе на редактирование того или иного модуля.

user_module_locks — Блокировки пользователем конкретного модуля

user_right_modules — список модулей которые можно редактирвать.

modules — список всех модулей на сайте.

Задача сделать блокировку отдельных страниц для совместного редактирования,
то есть чтобы страницу мог редактировать только один пользователь.

Я решил сделать так:

1. После того как пользователь заходит на страницу выполняется следующий запрос.

SELECT

users.user_id,
modules.module_id,
IF(user_edit_rights.user_id = users.user_id, 1, 0) AS user_can_edit_module,
my.module_id AS user_lock_module_id,
IF(other.user_id != users.user_id,1,0) AS another_user_lock_module

FROM users

INNER JOIN user_roles ON users.user_id = user_roles.user_id

INNER JOIN wedding ON wedding.id = user_roles.wedding_id

LEFT JOIN modules ON 1

LEFT JOIN user_edit_rights ON user_edit_rights.user_id = users.user_id AND user_edit_rights.wedding_id = wedding.id AND user_edit_rights.module_id = modules.module_id

LEFT JOIN user_module_locks AS my ON my.wedding_id = wedding.id AND my.user_id = users.user_id

LEFT JOIN user_module_locks AS other ON other.wedding_id = wedding.id AND other.module_id = modules.module_id

WHERE users.user_id = 3285
AND wedding.id = 72
AND modules.name = 'gifts'


Результат его выполнения выглядит примерно так:

user_id	module_id	user_can_edit_module	user_lock_module_id	another_user_lock_module
3285	10	0	2	0

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

Меня смущают 6 джоинов (в идеале 8-9) и постоянная необходимость выполнения этого запроса
и запроса на манипуляцыю (update, insert, delete) данных в таблице user_module_locks
данные в этой таблице будут постоянно изменятся при переходе пользователя от одной
страницы к другой. EXPLAIN данного запроса показывает что все SIMPLE и скорее всего
одновременного редактирования многими пользователями не будет (онлайн < 10 человек).

Больше всего меня интересует вопрос нормально ли это когда для получения полной
сущьности используется один запрос с большим кол-вом джоинов?

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

А также нормально ли когда первичный ключ состоит из 3х и более полей?

Comments

[xRay]

Какой тип используете MyISAM или InnoDB?

[pyatin]

InnoDB для каскадного удаления.

Answer 1

[slang]

Да, всё это нормально, и куча джойнов, и ключи, когда используется релятционная база для объектных моделей. Сделайте материализацию, за счёт избыточности данных создайте удобные условия для популярных выборок или используйте key-value storage.

Answer 2

[Jazzist]

Юзер может редактировать какую-то конкретную свадьбу, при этом не являясь ее заказчиком, ни являясь админом или менеджером? Если да — то такие вопросы:

— кто выдает разрешение на право редактирования
— можно-ли разрешения вынести из абстракции модуля БД (при этом возможно оставить абстракции в интерфейсе)

Еще вопросы
— роли пользователей меняются динамично? Есть большая уверенность в том, что это нужно именно в таком виде? Если да — тогда почему нельзя добавлять роль, как вариант целого значения поля, и просто сохранять ее описание — зачем отдельную таблицу под них?
— блокировки — только на отдельные свадьбы? Если да — то почему нельзя создать единую таблицу с привилегиями?

Вообще, вы правы — руки чешутся оптимизировать… и сильно оптимизировать. Правда есть небольшие сомнения в том, что можно что-то сильно полезное советовать по представленной информации. Советы будут намного более объективными, если взглянуть на ТЗ.

Comments

[Jazzist]

> А также нормально ли когда первичный ключ состоит из 3х и более полей?
нет

[Jazzist]

Вкратце о возможных направлениях «оптимизации»
1 вариант — если есть возможность сформулирвовать по ТЗ привилегии статично — не имеет смысла создавать дополнительных таблиц. Привилегии указываются флагами на уровне сущностей. При этом представленная вами структура уменьшается в 3-4 раза, первычный ключ — один, индексов — не более 3
2. Если есть нужда иметь динамические привилегии — к описанному в п. 1 добавляется единственная таблица с привилегиями (юзер, коррелирующая сущность, тип привилегии). В этом случае структура уменьшается в 2-3 раза, первичный ключ один, индексов не более трех.

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

InnoDB — можно, если подразумевается дейтсвительно большая нагрузка и вы реализуете механизм транзакций. На представленном этапе разработки это не имеет практического значения, именно эту «оптимизацию» можно отложить на потом.