MySQL - Структура для разрешений на объекты

Question

Что было бы идеальной структурой для пользователей> разрешений объектов.

Я видел много связанных должностей для общих разрешений или в каких разделах пользователь может получить доступ, который состоит из users, userGroups и userGroupRelations или что-то в этом роде.

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

Group 1 
    Group 2 
    Group 3 
    Group 4 
Group 5 
    Group 6 
Group 7 
    Group 8 
     Group 9 
     Group 10 

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

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

Моя текущая мысль, чтобы иметь таблицу пользователей, а затем таблица разрешений с колоннами, как:

permission_id (int) PRIMARY_KEY 
user_id (int) INDEX 
object_id (int) INDEX 
type (varchar) INDEX 
admin (bool) 
read (bool) 
write (bool) 
edit (bool) 
delete (bool) 

Это работало в прошлом, но новая система Я здание должно быть в состоянии быстро, и я не уверен, что это лучшая структура. Это также заставляет задуматься о том, что кому-то со всеми подгрупповыми правами группы сложнее.

Будет отдельная таблица для ролей пользователей/админов, что означает, что они могут изменять разрешения для пользователей ниже групп, которым они могут управлять.

Итак, в качестве вопроса, следует ли использовать вышеуказанную структуру? Или может кто-то указать мне в сторону лучшего?

---

EDIT

Альтернатива заключается в создании таблицы разрешений для каждого типа объекта.

Answer 1

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

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

Будьте осторожны с «необходимо быстро масштабировать». Трудно догадаться, не имея реального опыта производства, что действительно нуждается в масштабируемой системе.

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

Ваша схема связана с объектами. Вы хотите, чтобы ваш первичный ключ и ваш уникальный индекс (user_id, object_id)? То есть, вы хотите, чтобы каждый пользователь имел либо ноль, либо одну запись разрешения для каждого объекта? Если это так, используйте первичный ключ для принудительного использования этого, вместо использования суррогатного ключа permission_id, который вы предлагаете.

Для ваших объектов, которые существуют в иерархии, вы должны сделать один из двух вариантов Systemwide:

1. грант на объект с подобъектами неявно предоставляет доступ только объекта, или ...

2. он также предоставляет доступ ко всем подобъектам.

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

Второй выбор затрудняет определение того, имеет ли пользователь доступ к определенному объекту, потому что вам нужно пройти иерархию объектов к корню дерева, ищущему гранты доступа к родительским объектам, при проверке того, имеет ли пользователь доступ , Эта проблема производительности должна доминировать над принятием решений. Будут ли ваши пользователи создавать несколько объектов и часто обращаться к ним? Или они будут создавать много объектов и подобъектов и получать к ним доступ редко? Если доступ более частый, чем создание, вам нужен первый выбор. Возьмите накладные расходы на предоставление разрешения на время создания объекта, а не на запрос поиска разрешения на время доступа к объекту.

Я думаю, что первый выбор, вероятно, выше. Я предлагаю эту таблицу макет:

user_id (int) 
object_id (int) 
type (varchar) (not sure what you have this column for) 
admin (bool) 
read (bool) 
write (bool) 
edit (bool) 
grant (bool) 
delete (bool) 
last_update (timestamp) 
last_updated_by_user_id (int) 
primary key = user_id, object_id. 

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

user_id (int) 
object_id (int) 
permission_enum (admin/read/write/edit/grant/delete) 
type (varchar) (not sure what you have this column for) 
last_update (timestamp) 
last_updated_by_user_id (int) 
primary key = user_id, object_id, permission_enum