AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.03.2013, 11:55   #21  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от fed Посмотреть сообщение
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется
__________________
С уважением,
Вячеслав
Старый 04.03.2013, 11:59   #22  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
А смысл? Если физическое хранение полей в ней - то возвращаемся к тому, что было в АХ 2012 без R2. Т.е. с кучей джойнов.
Т.е. какой резон давать выбор? Опять-таки - я смотрю глазами практика, который не будет лишний раз заморачиваться с реализацией, если есть возможность не заморачиваться .
Что дадут джойны ? Даже в случае с LedgerJournalTrans, где такая архитектура может быть оправдана - там лишние джойны явно не приведут к увеличению производительности.
__________________
Возможно сделать все. Вопрос времени
Старый 04.03.2013, 12:01   #23  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от pitersky Посмотреть сообщение
А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется
Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...
Старый 04.03.2013, 12:08   #24  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...
Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?
__________________
Возможно сделать все. Вопрос времени
Старый 04.03.2013, 12:14   #25  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?
Нет. Если ты в базовую таблицу засовываешь, допустим, 80 дополнительных полей, они (даже если там нет данных), будут занимать какое-то (пусть небольшое) место в записи. Чем больше средний размер записи, тем большее количество страниц должен прочитать сервер при извлечении данных.
Кроме того - если мы добавим совсем уж много полей в базовую таблицу, то дочерние индексы тоже надо будет по ней строить. Это слегка усилит накладняк на обновление (не во всех случаях, но, в общем, в каких-то случаях - может увеличить).
За это сообщение автора поблагодарили: sukhanchik (3).
Старый 04.03.2013, 12:22   #26  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Кстати об индексах. В дочерних таблицах можно в состав индекса включать поля из базовых таблиц? А если это две разные физические таблицы?

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

Последний раз редактировалось S.Kuskov; 04.03.2013 в 12:32.
Старый 04.03.2013, 16:01   #27  
trud is offline
trud
Участник
Лучший по профессии 2017
 
1,038 / 1629 (57) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от fed Посмотреть сообщение
Очень, очень забавно. Версия 2012 выпускалась под флагом борьбы за нормализацию структур данных. В итоге - после столкновения с реальностью, в версии 2012R2 пришлось денормализовать те же данные до абсурдного состояния. Скрестить companyInfo и DirPartyTable - это уже денормализация за гранью добра и зла...
Думаю следующим шагом должна стать возможность создавать Relations на расширенных типах данных и постепенный отказ от ссылок по RecId. Здравый смысл все же взял верх над изначальной безумной реализацией
Старый 04.03.2013, 16:32   #28  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от trud Посмотреть сообщение
Думаю следующим шагом должна стать возможность создавать Relations на расширенных типах данных и постепенный отказ от ссылок по RecId. Здравый смысл все же взял верх над изначальной безумной реализацией
offtop, но не смог удержаться Microsoft вернет меню «Пуск»
Старый 01.05.2016, 22:45   #29  
Zabr is offline
Zabr
Участник
Axapta Retail User
 
1,200 / 345 (14) ++++++
Регистрация: 26.06.2002
Адрес: Москва
Проясните плиз ситуацию с индексами (AX2012 R2). В индекс на базовой таблице нельзя включить поле из дочерней, а в индекс на дочерней таблице - поле из базовой. Как быть ? Надеяться что SQL сам построит оптимальный план запроса без моего индекса? Действует ли на дочернюю таблицу индекс из базовой ? (в смысле, всегда ли SQL использует этот индекс, если я делаю запрос к дочерней таблице с участием полей из базовой таблицы)

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

UPD: Получается, если это две разные физические таблицы, то это уже материализованное представление нужно делать. Чем по сути объединённая таблица и является
Старый 20.09.2018, 19:08   #30  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Привет всем.
Коллеги, столкнулся со странной вещью.

Ax2012 R3 CU13

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

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

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

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

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

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

Последний раз редактировалось Logger; 20.09.2018 в 19:25.
Старый 20.09.2018, 19:22   #31  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Есть догадка что это связано с конвертацией приложения базы, что так сделали программисты ядра чтобы не делать конвертацию с ax4/2009 на 2012/R3

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

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

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

Последний раз редактировалось Logger; 20.09.2018 в 19:36.
Старый 21.09.2018, 17:28   #32  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Разобрался в чем проблема.

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

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

Указанный эффект можно получить если просто в обычной базе создать хранимку командой
X++:
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; 21.09.2018 в 18:16.
За это сообщение автора поблагодарили: sukhanchik (6), gl00mie (5), -DocSerzh- (1), S.Kuskov (2).
Старый 21.09.2018, 17:56   #33  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Вот тут о том же речь в комментариях.
https://blogs.msdn.microsoft.com/axs...on-check-list/
Теги
ax2012, inheritance, table inheritance, наследование таблиц, полезное

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: New Content for Microsoft Dynamics AX 2012 : October 2011 Blog bot DAX Blogs 0 27.10.2011 17:11
dynamics-ax: Interview with Microsoft's Lachlan Cash on his new role, AX 2012 and more Blog bot DAX Blogs 6 22.04.2011 14:55
axinthefield: Dynamics AX Event IDs Blog bot DAX Blogs 0 01.03.2011 22:11
daxdilip: Whats New in Dynamics AX 2012 (A brief extract from the recently held Tech Conf.) Blog bot DAX Blogs 7 31.01.2011 12:35
dynamics-ax: Modeling the world, with Microsoft Dynamics AX 2012 Blog bot DAX Blogs 0 25.01.2011 09:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 23:08.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.