i-neti: Фреймворк Extensible Data Security (XDS) в Dynamics 365 Finance for Operations

[trud]

Цитата:

Сообщение от fed

В такой ситуации, я бы аналитики продублировал в скрытые поля в таблице заказов или их строк, построил бы по ним индексы, обновлял бы их в update() или insert() на основании значений аналитик, ну и добавил бы эти поля в XDS

Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было

[fed]

Цитата:

Сообщение от trud

Так аналитика изначально была в строках(а форма заказов отображает шапки). Т.е. заказ показывается пользователю если есть хотя бы одна строка из того чем его подразделение торгует. Я не смог придумать как такое решить индексами и как вообще технически сделать подобную задачу. т.е. на каких-то объемах это просто начало тормозить. можно наверное как-то поиграться с материлизованными вью было

Ну при таком раскладе, надо было бы заводить отдельную таблицу с со списком имеющихся подразделений по заказу и при любом обновлении строки заказа, эту табличку обновлять. Ну а потом где-то в XDS прописывать exists join между заказом и этой таблицей. (Хотя честно говоря, я уже не помню как это делать. Я этим XDS пользовался всего пару раз и году в 2014-2015).

[trud]

Цитата:

Сообщение от fed

Ну при таком раскладе, надо было бы заводить отдельную таблицу с со списком имеющихся подразделений по заказу и при любом обновлении строки заказа, эту табличку обновлять. Ну а потом где-то в XDS прописывать exists join между заказом и этой таблицей.

Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить

[fed]

Цитата:

Сообщение от trud

Так я о том и говорю, что exists join где условие накладывается на привязанную таблицу - это по сути полный скан таблицы заказов при открытии формы(т.е. ты находишь сначала по индексу записи в фильтрующей таблице, потом ищешь все заказы которые под это попадают(так так на формах обычно сортировка по коду заказа), сортируешь их, и выводишь первые 10. Это отлично работает на малых объемах, но начиная с сотни тысяч уже тормозит и никакими индексами это не победить

Это не обязательно полный скап таблицы заказов при открытии формы Сиквел может оказаться достаточно умным чтобы сначала отобрать записи в этой дополнительной таблице и потом уже результат заджойнить через nested look к таблице заказов. Более того - он может в этой дополнительнойтаблице отобрать первые 10 или 20 записей по нужному подразделению и потом их быстренько по кластерному ключу приджойнить nested loop к таблице заказов. Ну еще вариант - добавить в шапку заказа 10 или 15 полей с кодами подразделений и по всем им построить индексы. Вариант не особо блестящий, но тоже может сработать.

[trud]

Цитата:

Сообщение от fed

Сиквел может оказаться достаточно умным чтобы сначала отобрать записи в этой дополнительной таблице и потом уже результат заджойнить через nested look к таблице заказов. Более того - он может в этой дополнительнойтаблице отобрать первые 10 или 20 записей по нужному подразделению и потом их быстренько по кластерному ключу приджойнить nested loop к таблице заказов.

Так он так и делает. т.е. у тебя миллион заказов и 3 подразделения. предположим у пользователя настоено 1. т.е. вначале отбирается 300тыс заказов в фильтрующей таблице, потом проверяет все эти 300к заказов(на форме же как правило указывается сортировка и отказывать от нее никто не хочет), из них выбираются 10.

Цитата:

Сообщение от fed

Ну еще вариант - добавить в шапку заказа 10 или 15 полей с кодами подразделений и по всем им построить индексы. Вариант не особо блестящий, но тоже может сработать.

так а это как поможет, выбирать то надо по "или", у пользователя может быть несколько подразделенией и т.п.

[fed]

Цитата:

Сообщение от trud

Так он так и делает. т.е. у тебя миллион заказов и 3 подразделения. предположим у пользователя настоено 1. т.е. вначале отбирается 300тыс заказов в фильтрующей таблице, потом проверяет все эти 300к заказов(на форме же как правило указывается сортировка и отказывать от нее никто не хочет), из них выбираются 10.

так а это как поможет, выбирать то надо по "или", у пользователя может быть несколько подразделенией и т.п.

По этой логике, даже без XDS, если у нас есть миллион заказов,то сначала этот милион сортируется, а потом из нее 10 заказов отбираются. Так что с XDS даже чуть легче ситуация, потому что надо не миллион отсортировать,а всего 300K

[fed]

Цитата:

Сообщение от trud

так а это как поможет, выбирать то надо по "или", у пользователя может быть несколько подразделенией и т.п.

Насколько я помню, XDS привязывается к роли и если у пользователя несколько ролей, то там как раз условия по "или" складываются (хотя могу что-то путать).