|
![]() |
#1 |
Участник
|
Так конкретный же кейс, фильтр по фин аналитике на строке заказа, какие фильтры и индексы будем добалять? Причем ребята с ролью "А" не видят подразделение "Б", а роль "Б" не видит "А" и не тоько на одной конкретной форме заказа, а вообще нигде, включая отчеты.
|
|
![]() |
#2 |
Участник
|
Цитата:
Цитата:
А старый Record level security остался в D365? |
|
![]() |
#3 |
Moderator
|
Цитата:
Сообщение от trud
![]() Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно
А старый Record level security остался в D365? P.S. Старого RLS не было уже в DAX2012 по моему. В целом - мне его нисколько не жалко. XDS в DAX2012 иногда подлгюкивал на моей памяти, но он все равно был намного более стабильным и работоспособным чем RLS. |
|
|
За это сообщение автора поблагодарили: EVGL (2). |
![]() |
#4 |
Участник
|
Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было
|
|
![]() |
#5 |
Moderator
|
Цитата:
Сообщение от trud
![]() Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было
|
|
![]() |
#6 |
Участник
|
Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить
|
|
![]() |
#7 |
Moderator
|
Цитата:
Сообщение от trud
![]() Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить
![]() ![]() |
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от trud
![]() Ну я встречал только негативные последствия(хотя тут наверное ошибка выжившего, когда все хорошо мне об этом не расскзаывали), кейсы - это фильтр на приджойненную таблицу
Как раз один из негативных случаев. Решать подобные вещи очень сложно - т.е. в итоге клиент перетасовал роли и подразделения таким образом чтобы можно было фильтровать по полю из шапки заказа(первоначально была строка), ну и добавили поле в шапку. Хотя в первый год все работало замечательно А старый Record level security остался в D365? RLS был в 2012, просто был не рекомендуемый . В 365 вроде прибили. |
|
|
|