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

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

Что лично мне не нравится в аксаптовой реализации, так это невозможность использовать поля из разных таблиц иерархии в одном индексе или табличной группе полей
Теги
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:34.