Сохранение прав доступа пользователей к строкам данных

У меня есть таблица с строками данных для разных экспериментов.Сохранение прав доступа пользователей к строкам данных

experiment_id data_1 data_2 
------------- ------ ------- 
     1 
     2 
     3 
     4 
    ..

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

Какой формат следует использовать для хранения разрешений? Просто таблица со строкой для каждого пользователя и столбец для каждого эксперимента с Boolean? И в таком случае мне пришлось бы добавить строку в эту таблицу каждый раз, когда будет добавлен эксперимент?

user experiment_1 experiment_2 experiment_3 .. 
---- ------------ ------------ ------------ -- 
user_1  True    False   False  .. 
user_2  False   True   False  .. 
..

Любая справочная литература по данной теме также будет большим, предпочтительно, связанные с sqlite3 функциональность, так что мой текущий дб бэкенд.

источник

2016-09-19 nven

Я бы не добавлял столбцы за эксперимент. Но это я. См. [Таблицы соединения] (http://stackoverflow.com/a/32620163), игнорируя часть csv. Остальное относится – Drew

Вы пытались найти решение, включающее «таблицы перекрестных ссылок»? То есть Таблицы «Эксперимент», «Пользователь», «Пользователь_Эксперимент_Пермация»? – Frito

вам нужно узнать о [нормализации базы данных] (https: // ru.wikipedia.org/wiki/Database_normalization). Это должно привести к вашему окончательному дизайну: подсказка: то, что вы предлагаете, будет работать, но будет кошмаром для обслуживания. –

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

Table: Experiment 
Experiment_Id | data_1 | data_2 
----------------------------------- 
1    | ...  | ... 
2    | ...  | ... 

Table: User 
User_Name | Password | ... 
---------------------------- 
User1  | ... 
User2  | ... 

Table: User_Experiment_Permissions 
User_Name | Experiment | Can_Read | Can_Edit 
-------------------------------------------- 
User1 | 1   | true  | false 
User2 | 1   | false | false 
User1 | 2   | true  | true 
User2 | 2   | true  | false

Как видите, в новой таблице мы ссылаемся как на пользователя, так и на эксперимент. Это позволяет нам контролировать мелкие зерна по отношению между пользователем и экспериментом. Кроме того, если у этого отношения появилось новое разрешение, такое как can_delete, вы можете просто добавить его в новую таблицу перекрестных ссылок со значением по умолчанию, а изменение будет изменено в вашу систему :-)

источник

2016-09-19 16:22:07 Frito

Я думаю, что это не будет масштабироваться, это хорошо для небольшого числа пользователей и разрешения, но в случае, если эта таблица будет иметь большое количество пользователей и разрешение, это затруднит обновление, удалит записи –

@AmrMagdy That может быть правдой. Мы действительно не знаем, каковы требования к масштабам/производительности OPs. Всегда есть соображения и оптимизации, которые понадобятся для работы программного обеспечения в масштабе. Спасибо, что указали на это! – Frito

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

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

- В случае, если вы будете использовать эти значения в запросе у вас есть два варианта, например, чтобы получить пользователь с помощью конкретного Допуста

Создания bit masking числа полех и каждый биты будет представлять собой разрешение, и вы можете используйте AND/OR для получения любых комбинаций необходимых вам разрешений.
- Преимущество: небольшой размер, очень эффективный
- Неудобство: комплекс для реализации
Создание поля для каждого разрешения (ваше решение).
- Преимущество: Для того, чтобы легко добавить
- Недостаток: Есть редактировать схемы с каждого разрешения

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

{"experiment_1": 1, "experiment_2": 0, "experiment_3": 1}

источник

2016-09-19 16:42:33

Метод JSON - это именно то, что я думал делать. У меня будет таблица с основным ключом, являющимся именем пользователя, а столбец разрешений - блоком JSON. Единственная проблема заключается в том, что мне придется разбирать строки json, генерировать кортеж, содержащий все экспериментальные_иды, а затем выполнять вызов SQL. Таким образом, в середине будут два вызова с некоторыми издержками python. Я был обеспокоен тем, что, хотя это слово будет легко реализовать, оно не будет масштабироваться очень хорошо. – nven

Сохранение прав доступа пользователей к строкам данных

ответ

Смежные вопросы