Я працюю над додатком, де користувачі мають різні дозволи на використання різних функцій (наприклад, читання, створення, завантаження, друк, затвердження тощо). Очікується, що список дозволів часто не змінюватиметься. У мене є кілька варіантів, як зберігати ці дозволи в базі даних.

У яких випадках варіант 2 був би кращим?

Варіант 1

Використовуйте асоціативну таблицю.

Користувач
----
UserId (PK)
Ім'я
Кафедра

Дозвіл
----
PermissionId (PK)
Ім'я

User_Permission
----
Ідентифікатор користувача (FK)
PermissionId (FK)

Варіант 2

Зберігайте бітову маску для кожного користувача.

Користувач
----
UserId (PK)
Ім'я
Кафедра
Дозволи

[Flags]
enum Permissions {
    Read = 1,
    Create = 2,
    Download = 4,
    Print = 8,
    Approve = 16
}

Чудове питання!

По-перше, давайте зробимо кілька припущень про "краще".

Я припускаю, що ви не дуже піклуєтеся про місце на диску - бітова маска ефективна з космічної точки зору, але я не впевнений, що це має велике значення, якщо ви використовуєте SQL-сервер.

Я припускаю, ви дбаєте про швидкість. Бітова маска може бути дуже швидкою під час використання обчислень, але ви не зможете використовувати індекс під час запитів бітової маски. Це не повинно мати великого значення, але якщо ви хочете знати, які користувачі мають доступ для створення, ваш запит буде приблизно таким

select * from user where permsission & CREATE = TRUE

(сьогодні в дорозі немає доступу до SQL Server). Цей запит не зможе використовувати індекс через математичну операцію - тож якщо у вас величезна кількість користувачів, це буде досить боляче.

Я припускаю, що ви дбаєте про ремонтопридатність. З точки зору ремонтопридатності, бітова маска не така виразна, як основний домен проблеми, як зберігання явних дозволів. Вам майже напевно довелося б синхронізувати значення прапорців бітової маски для декількох компонентів - включаючи базу даних. Не неможливо, але біль у спині.

Отже, якщо немає іншого способу оцінки "кращого", я б сказав, що шлях бітової маски не такий хороший, як зберігання дозволів у нормалізованій структурі бази даних. Я не згоден з тим, що це буде "повільніше, тому що вам потрібно зробити приєднання" - якщо у вас немає абсолютно нефункціональної бази даних, ви не зможете виміряти це (тоді як запит без переваг активного індексу може стати помітним повільніше з кількома тисячами записів).

Особисто я б використовував асоціативну таблицю.

Поле бітової маски дуже важко запитати та приєднатися до нього.

Ви завжди можете зіставити це з вашим переліченням прапорів C #, і якщо продуктивність стане, і випустіть рефакторинг бази даних.

Читаність при передчасній оптимізації;)

Зберігайте дозволи нормалізованими (тобто не у бітовій масці). Хоча це, очевидно, не є вимогою для вашого сценарію (особливо, якщо дозволи не часто змінюються), це значно полегшить і зробить запит очевидним.

Однозначної відповіді немає , тож робіть те, що вам підходить . Але ось мій улов:

Використовуйте варіант 1, якщо

• Ви очікуєте, що дозволи зростуть до багатьох
• Якщо вам може знадобитися зробити перевірку дозволу в самій збереженій процедурі бази даних
• Ви не очікуєте мільйонів користувачів, щоб записи в таблиці не зростали масово

Використовуйте варіант 2, якщо

• Дозволи будуть обмежені кількома
• Ви очікуєте мільйонів користувачів

Єдиний раз, коли я можу придумати, коли б я використовував поле бітової маски для зберігання дозволів, це коли ви дійсно обмежені тим, скільки фізичної пам’яті у вас .... як, можливо, на старому мобільному пристрої. По правді кажучи, обсяг збереженої пам'яті не вартий того. Навіть у мільйонів користувачів простір на жорсткому диску коштує дешево, і ви можете набагато простіше розширити дозволи тощо, використовуючи підхід без бітової маски (це про звітування про те, хто має які дозволи тощо).

Одне з найбільших головних болів, з яким я стикався, - це призначення дозволів користувачам безпосередньо в базі даних. Я знаю, що вам слід спробувати використовувати програму для адміністрування себе, і не надто багато з даними програми загалом, але іноді це просто необхідно. Якщо бітова маска насправді не є символьним полем, і ви можете легко побачити, які дозволи має хтось замість цілого числа, спробуйте пояснити аналітику тощо, як надати комусь доступ до запису тощо, оновивши поле ..... і моліться ваша арифметика правильна.

Це буде корисно, коли вони не зміняться у своїй структурі і будуть використовуватися завжди разом. Таким чином, у вас є невеликі зворотні поїздки на сервер. Вони також хороші з точки зору продуктивності, оскільки ви можете вплинути на всі права в одному призначенні змінної.

Мені особисто вони не подобаються ... У деяких додатках із високою продуктивністю вони все ще використовуються. Я пам’ятаю, як я використовував шаховий штучний інтелект, використовуючи їх, тому що ви можете оцінити дошку в одному порівнянні .. Працювати з цим боляче.

Я завжди зберігав би це нормалізовано, якщо не база даних просто не зберігає для вас запис, і ви ніколи не зробите з цим нічого, крім отримання та збереження. Сценарій для цього полягає в тому, що при вході в систему отримується рядок дозволу вашого користувача, а в коді сервера він обробляється та кешується. У цьому випадку насправді не має великого значення те, що воно денормалізоване.

Якщо ви зберігаєте його в рядку і намагаєтеся виконати роботу над ним на рівні БД, вам доведеться виконати гімнастику, щоб отримати дозволи для сторінки X, що може бути болісно.

Я не раджу використовувати бітову маску з таких причин:

• Індекс не можна використовувати ефективно
• Запити це складніше
• На читабельність / технічне обслуговування дуже впливає
• Пересічний розробник там не знає, що таке бітова маска
• Гнучкість знижена (верхня межа до числа бітів у ряді)

Залежно від ваших шаблонів запитів, запланованого набору функцій та розподілу даних, я б вибрав ваш варіант 1 або навіть щось просте, як:

user_permissions(
   user_id
  ,read     
  ,create   
  ,download 
  ,print    
  ,approve  
  ,primary key(user_id)
);

Додавання стовпця є модифікацією схеми, але я здогадуюсь, що для додавання привілею "Очищення" потрібен буде деякий код, щоб поєднуватися з ним, тому привілеї можуть не бути такими динамічними, як ви думаєте.

Якщо у вас є поганий розподіл даних, наприклад, 90% користувальницької бази не має єдиного дозволу, наступна модель також чудово працює (але розпадається при більших скануваннях (одне 5-стороннє приєднання проти однієї повної таблиці) сканування).

user_permission_read(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

user_permission_write(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

user_permission_etcetera(
   user_id
  ,primary key(user_id)
  ,foreign key(user_id) references user(user_id)
)

Ваші запити будуть виконуватися швидше, використовуючи перелік прапорів (бітову маску), оскільки вам не потрібно буде включати приєднання до асоційованої таблиці, щоб зрозуміти значення.