How Check Constraints MIGHT Improve Your Queries and Missing Index Requests

[Vadik]

Интересный пост, не совсем про Аксапту, но возможно кому-то пригодится

Цитата:

Say you’ve got an app that’s designed to store multiple companies in a single database – but you don’t actually use it that way. All of the data in a given database is actually for the same company
..
All of our app’s queries have CompanyCode in their WHERE clauses – even though that doesn’t really do any filtering, but the app is a 3rd party app that always filters for just the company you’re logged into

[Logger]

В 2012-й напрашивается навешать констрейнтов на поле Partition.

[fed]

Мне в подобной ситуации помогало, в некоторых случаях, создание filtered statistics.

[Ivanhoe]

В итоге какая рекомендация? Если один партишн - написать скрипт на все таблицы с простановкой его в contraint? И аналогично для компаний? И ждать повышения скорости работы всей системы?

[EVGL]

В D365FO прикончили Partitions.
https://docs.microsoft.com/en-us/dyn...cated-features

[fed]

Цитата:

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

В D365FO прикончили Partitions.
https://docs.microsoft.com/en-us/dyn...cated-features

В общем - микрософт опять закопал стюардессу. А могли бы просто не ломать виртуальные компании в DAX2012 и все жили бы долго и счастливо.

[EVGL]

Цитата:

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

А могли бы просто не ломать виртуальные компании в DAX2012 и все жили бы долго и счастливо.

Да. Была наивная и несостоятельная аргументация, почему сломали. Мол, целостность данных нарушалась. Можно подумать, что c entity нельзя нарушить целостность данных.

Потом появилась System administration > Setup > Configure cross-company data sharing. Работает отлично... для горсти таблиц. Стоит что-нибудь посерьезнее условий доставки выбрать, как появляется

Цитата:

Table CUSTTABLE is a Main table as specified by the table group and may not be shared.

В 8.0 вроде как можно, но только для избранных:
https://docs.microsoft.com/en-us/bus...-vendor-tables

[Ivanhoe]

изящно ушли в сторону. Все-таки, какая рекомендация для версий Акс 3.0 - 2012?

[fed]

Цитата:

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

изящно ушли в сторону. Все-таки, какая рекомендация для версий Акс 3.0 - 2012?

На самом деле, во всех версиях системы на сервер уходят запросы, где обязательно стоит dataareaId=='BLA' (ну и Partition=123456789). И в 99% случаев, система вполне в состоянии построить правильный план исполнения запроса со стандартными индексами и без constraints.
То есть - сам по себе метод интересный, но он полезен тогда, когда у тебя аномальное распределение данных в каком-то другом поле. Например если у тебя в системе 3-4 номенклатуры и есть индекс по inventTrans (itemId,DateStatus). Есть подозрение, что в этом случае, если прописать список номенклатур в check(), то система сможет использовать индекс для поиска по условию по дате без указания номенклатуры в where. То есть - механизм полезен для вырожденных случаев, а не для регулярных запросов.

[Alexius]

Цитата:

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

Все-таки, какая рекомендация для версий Акс 3.0 - 2012?

В случае одной DataAreaId и/или Partition я предпочитаю их уничтожать в АХ. Это уменьшает занимаемое место на дисках и главное в памяти, хотя и не на много при использовании сжатия. Еще улучшается статистика, т.к. первое поле в индексе имеет подробную статистику по значениям.

PS. По моим наблюдениям еще один бонус - это более высокая вероятность распараллеливания онлайн-перендексации. При наличии полей DataAreaId и/или Partition в начале большого индекса онлайн-переиндесация далеко не всегда распараллеливается, даже при явном указании MAXDOP.

[Logger]

Цитата:

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

В случае одной DataAreaId и/или Partition я предпочитаю их уничтожать в АХ.

А как вы Partition в аксапте уничтожаете? Редактируете определение таблички в AOT ?
(Для DataAreaId вроде ключ командной строки был)

[Alexius]

Цитата:

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

А как вы Partition в аксапте уничтожаете? Редактируете определение таблички в AOT ?

Да, поштучно, т.к. таблички бывают очень большие и времени на остановку системы нет.

[Raven Melancholic]

Кстати, совсем не факт, что SQL вообще начнет учитывать ограничения при построении плана запроса.
Так как такой способ не самый универсальный, то он вполне может почитать, что стоимость поиска наиболее оптимального плана может превысить стоимость самого выполнения пусть и не наиболее оптимального, но подходящего плана.
Заметил, что всякие ухищрения в подсказках про свои данные дает выигрыш только на какое-то время, а спустя некоторое время уже игнорируется. Вполне возможно, что как только что-то такое новое появляется, SQL это пробует рассмотреть в первую очередь, а дальше уже сморит на это среди других способов и не всегда доходит до наших стараний.