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

Question

Я сохраняю список «Пользователи» в таблице. Бизнес-логика приложения будет иметь ссылку на объект со всеми данными в этой таблице для текущего пользователя. И иметь возможность разрешить пользователю выполнять операции, если они имеют правильный доступ.

Мне интересно, что является лучшим способом хранения «уровней доступа»?

Один из способов, которым я собираюсь сохранить уровень доступа, является целым числом, а использование флагов C# для объединения нескольких уровней доступа, не требующих кучи полей, является ли это мудрым?

Create = 1 
Read = 2 
Update = 4 
Delete = 8 
FullAcc = 16 

Другой вариант я имею в виду, чувствует себя менее Elegent, но я видел, что это сделано много:

Read/Write = 1 
R/W + Delete= 2 
Full Access = 3 

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

Answer 1

Я всегда предпочитал первый подход с использованием флагов. Опасность заключается в том, что вы получаете слишком много уровней разрешений, и вам нужно продолжать расширять свое перечисление и начинать использовать огромные числа, и, возможно, вам придется изменить тип данных в вашей базе данных на большой int. Однако для чего-то вроде разрешений количество опций должно быть довольно ограниченным. Единственное, что я хотел бы сделать, это указать, что FullAcc определяется как сумма Create, Read, Update и Delete вместо отдельного объекта. Таким образом, вам не придется проверять, имеет ли пользователь разрешения Update или FullAcc, когда они пытаются что-то обновить.

Answer 2

Я бы выбрал вариант №1, потому что он дает мне отдельные флаги для каждого типа доступа.

Я также рекомендовал бы сохранить историю изменений с отметками времени.

Answer 3

Я бы отправил маршрут перечисления. Его строго типизированный, достаточно хорошо переносится между db и кодом (отличные от int и enums), вы можете использовать FlagsAttribute для объединения прав безопасности, а перечисления довольно гибкие, когда дело доходит до проблем с версиями (если вы не удалите или переименовать ранее определенные значения перечисления).

Answer 4

Ваша идея «флагов» более гибкая, позволяя вам любую комбинацию прав, если это когда-либо понадобится. Пункт «FullAcc» не должны быть определены в виде определенного числа в вашем перечислении, однако - это должно быть сочетание других флагов соединены через (как это, с несколькими опущены):

enum Rights { Create, read, Update, FullAcc = Create | Read | Update } 

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