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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.06.2017, 11:07   #201  
gl00mie is offline
gl00mie
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Most Valuable Professional
 
3,485 / 4399 (153) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.
Так была ведь задача выбрать запись из иерархии таблиц, не зная изначально точный "тип" записи, а потом, уже после выборки, иметь возможность сделать приведение типа к нужному наследнику и дальше работать с записью таблицы-наследника без перевыборки данных. Вариант с кучей outer join'ов оказался нежизнеспособным с т.з. производительности, пришли к одной таблице с полями всех-всех наследников, в которых могут быть значения NULL. Какие еще были варианты решить исходную задачу?..
Цитата:
Сообщение от fed Посмотреть сообщение
В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит.
Это хорошо работает, если заранее знать конкретный тип сущности, к которой идет обращение, и если не стоит задача последующего приведения типа родителя к наследнику.
Собственно, чем именно не нравится то, как это реализовано в Аксапте? Да, ядро всегда выбирает набор полей, равный объединению множеств полей всех таблиц-наследников для типа, "через который" идет обращение к таблице в иерархии. Так, если выбирать записи через DirPartyTable, то в выборку попадет под 150 полей (не считая DEL_-полей). Но если заранее более точно знать тип и выбирать, к примеру, DirPerson, то в выборке будет уже лишь 40 полей. При этом выборка через DirPartyTable даст в тех или иных записях кучу полей, содержащих NULL, ну и что с того? Длину строки SQL-запроса это увеличивает, но лишних данных, кроме тех, которые могут понадобиться для приведения к типам-наследникам, не гоняет.

Что лично мне не нравится в аксаптовой реализации, так это невозможность использовать поля из разных таблиц иерархии в одном индексе или табличной группе полей
Старый 29.06.2017, 11:50   #202  
fed is offline
fed
Moderator
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
Ex AND Project
Соотечественники
 
2,130 / 3893 (134) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Это хорошо работает, если заранее знать конкретный тип сущности, к которой идет обращение, и если не стоит задача последующего приведения типа родителя к наследнику.
Ну по моему - такая ситуация и случается в большинстве случаев. Если нужно сделать какой-то универсальный обработчик, то разумнее пробежаться в таблице супео-класса, и тупо потом найти конкретные потомки find'ом. А при нынешнем подходе, оно вытаскивает вообще всех потомков, хотя у меня в обработчике может быть логика только для 2-3 кейзов (а тяжелый outer join строится для всех кейзов, а не только для тех, которые мне реально нужны).
Старый 29.06.2017, 13:08   #203  
gl00mie is offline
gl00mie
Участник
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
MCBMSS
Most Valuable Professional
 
3,485 / 4399 (153) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Ядро и реализует универсальный обработчик - не ошибешься уже Пусть при этом вытаскиваются 150 полей вместо 40, но половина из них содержит NULL, т.е. доп.расходы на "лишний" трафик не столь велики, зато для корректного приведения типа отпадает необходимость повторно обращаться к БД и получать причитающиеся задержки на этом, а также переписывать бизнес-логику для перечитывания данных со всеми вытекающими последствиями, если где-то забыть это сделать.
Опять-таки, тяжелых outer join'ов нет со времен выхода AX 2012 R2, т.е. с декабря 2012-го года, а кто до сих пор работает на AX 2012 RTM - ну извините...
Вот ограничения по индексам - это, как мне кажется, куда серьезнее
Теги
sysoperation framework

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: The INSERT statement conflicted with the FOREIGN KEY constraint "FK_ModelElementData_HasModelId_LayerId". The conflict occurred in database "YourDataBaseName_model", table "dbo.Model" Blog bot DAX Blogs 0 23.05.2014 13:11
Dynamics AX Sustained Engineering: Performance issue in "Open Transaction Edit" form Blog bot DAX Blogs 0 26.10.2009 20:05
Зачем нужны "Параметры кодов аналитики"? Кирилл DAX: Программирование 2 16.04.2004 14:22
Зачем нужна "Потребность в номенклатуре" Tony Green DAX: Функционал 4 02.02.2004 00:24
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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