AX 2012 Наследование таблиц. Краткое описание механизма

[pitersky]

Цитата:

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

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

А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется

[sukhanchik]

Цитата:

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

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

А смысл? Если физическое хранение полей в ней - то возвращаемся к тому, что было в АХ 2012 без R2. Т.е. с кучей джойнов.
Т.е. какой резон давать выбор? Опять-таки - я смотрю глазами практика, который не будет лишний раз заморачиваться с реализацией, если есть возможность не заморачиваться .
Что дадут джойны ? Даже в случае с LedgerJournalTrans, где такая архитектура может быть оправдана - там лишние джойны явно не приведут к увеличению производительности.

[fed]

Цитата:

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

А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется

Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...

[sukhanchik]

Цитата:

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

Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...

Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?

[fed]

Цитата:

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

Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?

Нет. Если ты в базовую таблицу засовываешь, допустим, 80 дополнительных полей, они (даже если там нет данных), будут занимать какое-то (пусть небольшое) место в записи. Чем больше средний размер записи, тем большее количество страниц должен прочитать сервер при извлечении данных.
Кроме того - если мы добавим совсем уж много полей в базовую таблицу, то дочерние индексы тоже надо будет по ней строить. Это слегка усилит накладняк на обновление (не во всех случаях, но, в общем, в каких-то случаях - может увеличить).

[S.Kuskov]

Кстати об индексах. В дочерних таблицах можно в состав индекса включать поля из базовых таблиц? А если это две разные физические таблицы?

UPD: Получается, если это две разные физические таблицы, то это уже материализованное представление нужно делать. Чем по сути объединённая таблица и является

[trud]

Цитата:

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

Очень, очень забавно. Версия 2012 выпускалась под флагом борьбы за нормализацию структур данных. В итоге - после столкновения с реальностью, в версии 2012R2 пришлось денормализовать те же данные до абсурдного состояния. Скрестить companyInfo и DirPartyTable - это уже денормализация за гранью добра и зла...

Думаю следующим шагом должна стать возможность создавать Relations на расширенных типах данных и постепенный отказ от ссылок по RecId. Здравый смысл все же взял верх над изначальной безумной реализацией

[S.Kuskov]

Цитата:

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

Думаю следующим шагом должна стать возможность создавать Relations на расширенных типах данных и постепенный отказ от ссылок по RecId. Здравый смысл все же взял верх над изначальной безумной реализацией

offtop, но не смог удержаться Microsoft вернет меню «Пуск»

[Zabr]

Проясните плиз ситуацию с индексами (AX2012 R2). В индекс на базовой таблице нельзя включить поле из дочерней, а в индекс на дочерней таблице - поле из базовой. Как быть ? Надеяться что SQL сам построит оптимальный план запроса без моего индекса? Действует ли на дочернюю таблицу индекс из базовой ? (в смысле, всегда ли SQL использует этот индекс, если я делаю запрос к дочерней таблице с участием полей из базовой таблицы)

Цитата:

Сообщение от S.Kuskov

Кстати об индексах. В дочерних таблицах можно в состав индекса включать поля из базовых таблиц? А если это две разные физические таблицы?

UPD: Получается, если это две разные физические таблицы, то это уже материализованное представление нужно делать. Чем по сути объединённая таблица и является

[Logger]

Привет всем.
Коллеги, столкнулся со странной вещью.

Ax2012 R3 CU13

Открываю обозревателем табличку с наследованием. В логе запросов видно, что идет запрос с джоином к разным табличкам, т.е. данные в SQL физически хранятся как в Ax2012 RTM.

Как такое может быть ?
Версия точно Ax2012 R3 CU13
Рядом стоит другой аос с такой же версией, у него запросы нормально ходят.
Побайтно сравнил exe / dll файлы аосов - все совпадает.

Проверял на DirPartyTable и AgreementHeader.

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

Как от этого избавиться ?

База создана slipstream инсталлятором.

[Logger]

Есть догадка что это связано с конвертацией приложения базы, что так сделали программисты ядра чтобы не делать конвертацию с ax4/2009 на 2012/R3

Т.е. идет конвертация формата ax4/2009 --> 2012 RTM
а потом 2012 RTM --> 2012 R3

И я заглянув под капот увидел промежуточное состояние когда ядро R3 при синхронизации использует формат хранения RTM.

Но все равно хочется разобраться, тем более что выбран режим "Контрольный список обновления кода AOD".
Контрольный список обновления данных еще не запускали.

[Logger]

Разобрался в чем проблема.

Если база и аос устанавливается в режиме "Register database for upgrade from Microsoft Dynamics AX 4.0 or Microsoft Dynamics AX 2009" то инсталлятор прописывает в БД хранимку TABLEPERTYPEINHERITANCEMODE которая возвращает 1. Также в табличке SYSGLOBALCONFIGURATION создает запись с NAME = TABLEPERTYPEMODE

После этого аос считает что иерархию табличек надо хранить как в RTM версии в режиме одна табличка на одну табличку иерархии.

Указанный эффект можно получить если просто в обычной базе создать хранимку командой

USE [BASE_NAME]
GO

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE PROCEDURE [dbo].[TABLEPERTYPEINHERITANCEMODE] AS SELECT 1
GO

и рестартовать аос. На что влияет запись в SYSGLOBALCONFIGURATION пока неясно - похоже что ни на что.

Касательно задачи конвертации базы из ax4/2009 в формат 2012 R3 - то судя по всему предположение (что конвертер с предыдущих версий конвертирует базу в RTM формат) оказалось правильным и база в 2012-й сперва создается в режиме TABLEPERTYPEINHERITANCEMODE (так как инсталлятор создает ее с хранимкой) а после импорта / конвертации данных из ax4/2009 запускается класс SysDataUpgradeSCscTPT2TPH который и конвертирует уже способ хранения табличек в "плоский" режим. А в конце грохает хранимку и запись в SYSGLOBALCONFIGURATION (см. методы getStoredProcCleanupStatement и isInUnFlattenMode).

[Logger]

Вот тут о том же речь в комментариях.
https://blogs.msdn.microsoft.com/axs...on-check-list/