Наследуемые таблицы (DAX2012)

[DesparioN]

Добрый день!

Столкнулся с ограничением на таблице: невозможно указать свойство SupportInheritance, если уже существуют поля.

С чем связано такое ограничение? И насколько страшно будет, если это свойство поменять джобом (если конечно это возможно)?

[oip]

Цитата:

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

С чем связано такое ограничение?

Цитата:

Create a derived table
Next, create a derived table, and set the SupportInheritance property to Yes. Set the Extends property to point to the table on which the derived table is based. Set these properties before you create any fields for the table. This will help ensure that all fields in tables in the hierarchy have unique names and IDs, which is necessary for the run time to work correctly. It also makes it possible to choose different storage models, such as storing all types in a single table, without causing name collisions.

(с) Inside Microsoft Dynamics AX 2012

[Zabr]

Есть три таблицы, 2-я наследуется от 1-ой, 3-я от 2-ой.
Table1 -> Table2 -> Table3.

К 3-ей таблице выполняется запрос по трем полям, который работает несколько медленно. Полагаю, что дело в отсутствии индекса со всеми этими полями. В таблице 3 миллиона записей, но тормозит так, будто их 100 млн. Однако сделать такой индекс не представляется возможным, поскольку 1-е поле из table1, 2-е поле из table2, 3-е поле из table3.

Вопрос: как быть ? Поможет ли создание 3-х индексов в каждой таблице отдельно по тому полю, которое есть в ней? (мне кажется,.что не поможет)

Возможно, вопрос дурацкий, или ответ давно известен - но я его не знаю. И лучше спросить, чем не спросить.

[sukhanchik]

Цитата:

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

Вопрос: как быть ? Поможет ли создание 3-х индексов в каждой таблице отдельно по тому полю, которое есть в ней? (мне кажется,.что не поможет)

Может немного помочь создание индекса по наиболее селективному полю (т.е. по полю, в котором содержится наибольшее количество уникальных данных). Но это будет частичное ускорение (в идеале - нужен индекс по трем полям, которые будут расположены в индексе в порядке убывания селективности).

Ну а в общем случае всегда может помочь индекс, созданный на стороне БД вместе с триггером, запрещающим удалять индекс из таблицы на этапе синхронизации. Т.е. как только количество таблиц с большим объемом данных переваливает некоторое значение - становится оправданным управление индексами изнутри БД, а не из АХ.
Правда в случае с облачной D365FO с управлением БД несколько сложнее, но там вопрос спорный вообще, как работать с большими объемами.

[SRF]

Цитата:

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

Однако сделать такой индекс не представляется возможным, поскольку 1-е поле из table1, 2-е поле из table2, 3-е поле из table3.

В среде разработки нет, а вот экспортом\импортом через xpo файлик вроде работает, по крайней мере в R3, я проверял по EcoResProductMasterConfiguration\EcoResProductMasterDimensionValue, создал индекс на EcoResProductMasterConfiguration по полю RetailDisplayOrder из EcoResProductMasterDimensionValue.

[Zabr]

Цитата:

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

В среде разработки нет, а вот экспортом\импортом через xpo файлик вроде работает, по крайней мере в R3.

После импорта такой индекс стал виден в среде разработки?
PS У меня R2.

[SRF]

Да, поля там видны и при этом синхронизация проходит нормально.

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

Возможно это ограничение самой ранней версии механизма наследования в 2012, насколько я помню до r2 базовые и дочерние таблички были физически разными объектами на скл, поэтому такой индекс действительно нельзя было создать в принципе.

[Владимир Максимов]

В главной таблице создай индекс по полю InstanceRelationType.

Почему-то по этому полю индекс автоматически не создается. Как следствие, любой запрос по вторичным таблицам включает в себе фильтр по этому полю, а индекса такого нет.

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

Впрочем, возможно имеет смысл создать индексы во всех 3 таблицах по каждому из полей. Но в главной таблице в индекс по первому полю добавить еще InstanceRelationType. А SQL уже сам выберет какой из этих 3 индексов будет выгоднее использовать

[sukhanchik]

А насколько индекс по полю InstanceRelationType помогает?
Т.е. в теории - уникальных значений в нем явно немного и максимум, что он делает - это "делит" данные разных (в АОТе) таблиц. Грубо говоря, для выборки по CompanyInfo - он может помочь, а для выборки по DirPartyTable - в общем-то не очень.

[Zabr]

В 1-ой таблице индекс по InstanceRelationType был - добавил после него поле из запроса.
В 2-ой таблице индекс по полю из запроса был.
В 3-ей таблице индекса по полю из запроса не было - создал.
Существенной разницы от того что было до создания индексов я не заметил.
Но все равно спасибо.
С созданием индекса напрямую в SQL экспериментировать не хочу.