Прослушивание параметров SQL Dax

[Logger]

К слову о фиксе в аксапте по проблеме Parameters sniffing.
Почему они (MS) применили такой подход с включением литералов только для DataareaId и PartitionID?
Ведь в базе есть еще куча полей с неравномерно распределенными значениями. Например, любое поле с енумом, обозначающим какой-то статус - уже кандидат на эту проблему. Или еще любят в коде накладную от платежа отличать по заполненности поля CustTrans.Invoice и.т.п.

Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент.

[Vadik]

Цитата:

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

Почему бы не дать возможность для директивы forceLiterals действовать только на определенный список полей или зашить его в настроечной табличке типа SqlStorage ? Или в свойстве табличного поля в AOT такое свойство сделать. Получился бы гибкий, универсальный инструмент

А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?
Нунафиг, лучше уж на уровне приложения и запроса. Placeholders с одним планом на компанию (продуктивов с несколькими partition не видел пока) в большинстве случаев работают приемлемо (не зря же за SQL Server с его оптимизатором денег просят), и пилюли в виде forceliterals можно только в самых запущенных случаях прописывать

[Logger]

Цитата:

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

А кто такую гибкую конфигурацию на 2000+ таблиц поддерживать будет - консультанты ? А как быть если таблиц и статусов в запросе участвует более одного?

А в чем проблема ? Поддерживать будут программисты и админы. Смотря кому ближе. Тем более что никто не заставляет все значения заполнять - можно вообще не заполнять. Если ничего не заполнено - то обычное поведение, а дальше по желанию - для тех кто хочет заморочиться.
Сейчас ведь тоже можно настраивать хранение табличек и индексов по тейблспейсам в SqlStorage. Никому это не мешает - наоборот очень удобно и гибко. Кому надо - настроили. кому не надо - он про это и не помнит.

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

По-моему, это было бы очень удобно и эффективно.

[skuull]

Цитата:

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

По-моему, это было бы очень удобно и эффективно.

Добавте предложение на connect, а мы с радостью проголосуем

[gkochkin]

Цитата:

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

Ведь в базе есть еще куча полей с неравномерно распределенными значениями.

Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..

[Logger]

Цитата:

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

Буду благодарен за подробности про возможные поля с неравномерно распределенными значениями, я хотел бы их исследовать на своей системе..

Таких полей много.
Я думаю имеет смысл что-то для них менять только если явно есть подозрение на проблемы.

Например:
InventTrans.statusIssue
InventTrans.statusReceipt
CustTrans.invoice
VendTrans.invoice
Как правило еще InventDim.InventLocationId
90 % значений ходит по 1-2 складам.