Ефективна робота обмежень доступу до даних на рівні записів

1. Режими накладення обмежень

2. Відмінність між простим і складним обмеженням

3. Принципи трансляції обмеження доступу на рівні записів у запит до СУБД

4. Як написати ефективні обмеження доступу на рівні записів

У статті наводиться умовний поділ обмежень прав доступу на рівні записів на прості та складні; показано, як ці обмеження впливають на запит до СУБД; надаються рекомендації щодо написання ефективних обмежень на рівні записів.

1. Режими накладення обмежень

Існує 2 режими накладення обмежень на рівні записів. Перший, зі словом ДОЗВОЛЕНІ в запиті, використовується для виключення з результату вибірки записів, які користувачеві заборонені (наприклад, виведення списку документів). Другий, без слова ДОЗВОЛЕНІ, не містить фільтра для відсівання заборонених записів, але визначає поведінку механізму роботи з базою даних так, щоб під час спроби доступу до заборонених даних виник виняток.

2. Відмінність між простим і складним обмеженням

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

Обмеження доступу на рівні записів, що задаються для об’єктів метаданих, можна поділити на 2 види: прості та складні. До простих належать обмеження, які мають лише одну таблицю в розділі З (і ця таблиця — захищувана). У цьому разі обмеження доступу задається лише за допомогою реквізитів цієї таблиці, без використання з’єднань з іншими таблицями. Неявні з’єднання (звернення через крапку до реквізиту посилального типу), що додаються до запиту автоматично, переводять обмеження до категорії складних. До складного класу обмежень належать запити з більш ніж однією таблицею в розділі З.

Іноді обмеження, яке виглядає простим, насправді виконується як складне обмеження. Це трапляється, коли обмеження задано для регістру залишків або регістру бухгалтерії, оскільки в цьому разі механізм роботи з базою даних захищає не лише таблицю рухів цих регістрів, а й таблицю залишків. Таким чином, запит до таблиці залишків отримує обмеження, задані для регістру. І щоб включити ці обмеження до запиту до СУБД (щоб мати доступ до реквізитів регістру), механізм роботи з базою даних додає таблицю рухів до умови обмежень доступу.

3. Принципи трансляції обмеження доступу на рівні записів у запит до СУБД

Розглянемо найпростіший випадок, коли запит вибирає дані з однієї таблиці.

У разі, якщо запит містить слово ДОЗВОЛЕНІ, просте обмеження буде додано до розділу ДЕ вихідного запиту. Запит до СУБД отримає додаткові інструкції щодо відбору лише тих записів, які користувачеві дозволено бачити, і від СУБД надійдуть лише ті дані, які користувачеві дозволені.

У разі, якщо запит не містить слова ДОЗВОЛЕНІ, запит до СУБД будується інакше. У такому запиті створюється додаткова колонка-індикатор, яка містить ознаку, доступний чи ні запис цього рядка. Якщо будь-який запис є недозволеним, то механізм роботи з базою даних перериває виконання запиту та створює виняткову ситуацію. Проте дані, доступні в цей момент, можуть бути виведені до журналу реєстрації, якщо налаштовано детальну реєстрацію доступу (подія ОтказВДоступе).

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

Складні обмеження доступу на рівні записів потрапляють до запиту до СУБД у вигляді підзапитів. Це означає, що СУБД виконує підзапит зі складними обмеженнями для кожного потенційного запису. Якщо складних обмежень у запиті декілька (а деякі з них можуть бути додані неявно — під час звернення через крапку до реквізиту посилального типу), то для кожного із записів виконується не один підзапит, а більше: стільки, скільки складних обмежень включено до запиту до СУБД. Варто зазначити, що сучасні СУБД можуть оптимізувати отримані запити, і доволі часто оптимізація допомагає скоротити час виконання запиту. Але іноді буває так, що оптимізатор СУБД обирає не найоптимальніший план, і запит виконується довше, ніж можливо.

4. Як написати ефективні обмеження доступу на рівні записів

Як було показано вище, складні умови призводять до радикального ускладнення запиту. Якщо використовувати прості обмеження на рівні записів, то запити до СУБД із такими обмеженнями будуть простішими та добре прогнозованими за часом виконання. Тому рекомендується реквізити, від яких залежить доступність записів, включати до складу самого об’єкта конфігурації, а не звертатися до них "через крапку".

Крім цього, бажано індексувати реквізити, які використовуються в обмеженнях доступу. Це дає СУБД можливість використовувати індекс для відбору записів, що відповідають обмеженню на рівні записів. Однак слід зауважити, що такі індекси ефективні лише у випадках порівняння реквізиту на рівність; якщо ж порівняння відбувається на більше чи менше або входження до діапазону, то кожен такий випадок необхідно аналізувати окремо, і загальну рекомендацію тут дати складно.