Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
Доброго дня. Имеется центральная БД с которой работает n, нет n - мало, m филиалов. В настоящий момент фильтрация данных разрешенных им для просмотра организуется по признаку региональной принадлежности клиентов с которыми они работают. Плюс к этому каждый юзер может получить от администратора системы разрешения на просмотр конкретного клиента, или на группу клиентов сгруппированных по определенному признаку. Организовано это дело в виде табличной функии выцыпляющей из параметров подключения юзера из него его филиал и далее по всем критериям клиентов. Работает это безобразие с довольно приемлемой скоростью. Но вот возникла задача классификации клиентов по иерархическому принципу и в соответствии с этой иерархией выдавать разрешения на просмотр. Типа: клиенты из Тюмени, относящиеся к химической промышленности, с улицы Ленина, с годовым оборотом от m куе в год и т.д. Причем разрешения могут быть выданы на любом уровне иерархии. Меня терзают подозрения, что online это будет счетаться ох как не быстро, возникает идея, а что если при входе юзера в систему сразу расчитывать всех разрешенных ему клиентов и хранить их в БД до окончания работы с приложением, что скажите? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 17:11 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
1) Если надо видеть нового клиента, без перегрузки приложения то допуска определяются в момент внесения клиента (изменении старого). 2) Если не обязательно то в момент входя в систему. 3) Если совсем не критично то ночью для всех. 4) Если допуска к новым клиентам определяются администратором, то по кнопке у администратора. Либо комбинация из этих пунктов, выбирайте... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 17:50 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
предлагаю расчитывать на входе не всех клиентов, а записи классификатора, которым соответствуют разрешенные клиенты, тогда если разрешения будут выдаваться только для классификатора, то первое ограничение частично отпадет, перегружаться надо будет только если изменились данные в классификаторе (что происходит значительно реже). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.05.2005, 18:01 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
rcryoпредлагаю расчитывать на входе не всех клиентов, а записи классификатора, которым соответствуют разрешенные клиенты, тогда если разрешения будут выдаваться только для классификатора, то первое ограничение частично отпадет, перегружаться надо будет только если изменились данные в классификаторе (что происходит значительно реже). из личного опыта. В своей системе управления правами - правила назначения хранятся в одних таблицах, на этих таблицах стоят триггеры, которые при изменении правил генерируют в другую - результирующую таблицу истинные права конкретного пользователя. Она, конечно, довольно большая, но все же искать в ней быстрее, чем генерировать на лету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 02:32 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
К древесной таблице надо иметь доп.таблицу (два поля ID, ParentID) с перечислением всех пар комбинаций пути от листьев до корня дерева. Тогда выбирая произвольный элемент дерева и объединяя его с этой таблицей получите ВСЕХ ПОТОМКОВ ЭТОГО УЗЛА в т.ч. и этот узел. Доп.таблица будет очень длинной но узкой. Рулить её можно триггерами. Скорость выборок будет вполне приличная. Очень удобно делать отчёты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 11:10 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
автор результирующую таблицу истинные права конкретного пользователяесли я правильно понял, то в этой таблице КоличествоЗаписей=КоличествоЮзеров*Сумма(КоличествоЗаписейВоВсехТаблицахБДНаКоторыеРаздаютсяПрава) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 12:06 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
Проблема снимается изменением в методе организации защиты. Постановка задачи - защита к каждой записи - это перебор. Записи из таблиц в серьезной системе не выбираются на экран все под ряд. Обычно есть некоторый фактор, по которому они фильтруются. В данном случае – это подразделения. Допустим, нет ни какой защиты, и мы выбираем записи, относящиеся к Тюмени. Тогда каким то образом выбирается значение «Тюмень» из фактора подразделений, который очевидно является деревом. Это значение служит фильтром для отображения записей на экране (или вывода из в отчет). Система умеет использовать это значение для фильтрации. Она выдаст в результате набор записей, соответствующий «Тюмени». Еще раз отметим, что нет ни какой защиты, но система выдает указанный набор записей. Но если система может выдать набор записей по указанному фильтру, то достаточно организовать защиту к значениям этого фильтра. Те ветки, к которым у пользователя нет доступа, он не сможет отобразить на экране, не сможет выбрать из них значения для фильтрации, а следовательно и не сможет добраться до тех записей, которые относятся к этой ветке фактора учета. Так организована защита в БАС . Есть набор ролей пользователей, есть таблица доступа ролей к факторам учета. Подключить пользователя к массиву записей – проставить «птичку» для его роли напротив заданной ветки фактора учета. Ни каких дополнительных таблиц. Все делается мгновенно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:05 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
Если я понимаю Вас правильно, то речь идет об организации секурити на уровне GUI, но ведь есть такая вещь, как QA и что тогда ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:16 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
EasygoingЕсли я понимаю Вас правильно, то речь идет об организации секурити на уровне GUI, но ведь есть такая вещь, как QA и что тогда ?А можно расшифровать GUI и QA? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:18 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
GUI - Graphic user interface QA - Query Analizer ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:20 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
EasygoingGUI - Graphic user interfaceДа речь идет об обычных пользователях, которые работают из интерфейса. EasygoingGUI QA - Query AnalizerА разве есть шансы защитить участки записей от программистов, которых пустили в базу данных из QA? (Я работаю c MS SQL). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:24 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
Тут не только о программистах речь идет, у Вас ведь юзеры имеют логины на сервере, так? Соответственно они имеют возможность выполнять запросы к нему и соответственно вне интерфейса могут выполнять запросы с любыми параметрами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 13:47 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
EasygoingТут не только о программистах речь идет, у Вас ведь юзеры имеют логины на сервере, так? Соответственно они имеют возможность выполнять запросы к нему и соответственно вне интерфейса могут выполнять запросы с любыми параметрами.Все пользователи входят в систему со своих клиентских рабочих мест. Если это не программисты, то на ихних компьютерах есть только один путь подключиться к базе - запустить приложение, т.е. добраться только через интерфейс. Если пользователю на клиентской машине устанавливается инструментарий программиста или администратора БД, и этот юзер умеет им пользоваться, то его можно образно назвать "программистом". От юзера с такими вомозможностями, если его уже пустили в базу данных, защитить отдельные участки таблицы можно только теоретически. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 14:06 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
> В настоящий момент фильтрация данных разрешенных им для просмотра > организуется по признаку региональной принадлежности клиентов с которыми > они работают. А нормальный access control чем не подошел? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 17:32 |
|
||
|
Фильтрация данных на основе иерархической классификации.
|
|||
|---|---|---|---|
|
#18+
PVPЕсли пользователю на клиентской машине устанавливается инструментарий программиста или администратора БД, и этот юзер умеет им пользоваться, то его можно образно назвать "программистом". От юзера с такими вомозможностями, если его уже пустили в базу данных, защитить отдельные участки таблицы можно только теоретически. Не скажите, например организовав доступ к данным через процедуры и запретив всем кроме DBO просмотр таблиц. А внутри процедуры можно запрещать доступ построчно, либо даже колонками забивая null защищенные поля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2005, 17:38 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33083993&tid=1545850]: |
0ms |
get settings: |
7ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
262ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
30ms |
get tp. blocked users: |
1ms |
| others: | 228ms |
| total: | 563ms |

| 0 / 0 |
