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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.03.2013, 11:43   #1  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
Старый 04.03.2013, 11:55   #2  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,514 / 435 (18) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от fed Посмотреть сообщение
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется
__________________
С уважением,
Вячеслав
Старый 04.03.2013, 12:01   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от pitersky Посмотреть сообщение
А зачем? По мне, так наоборот - пусть всё физически лежит в одной таблице, а логически/визуально - разделяется
Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...
Старый 04.03.2013, 12:08   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Ну разрастание числа полей в таблице - тоже не подарок с точки зрения производительности. Если некоторая дочерняя сущность содержит 20-30 полей и составляет менее чем 10% от родительской таблицы - есть большой резон выложить ее в дочернюю таблицу. Поскольку при таких раскладах, накладняк на джойны будет перевешен экономией времени на доступе к оставшимся 90% записей. Лишние поля в таблицах - они тоже не бесплатны с точки зрения времени доступа и занимаемого пространства. Опять таки - про обновление лишних индексов по родительской таблице стоит подумать...
Короче говоря - нормализацию не просто так придумали. Просто нужно не доводить ее до абсурда...
Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?
__________________
Возможно сделать все. Вопрос времени
Старый 04.03.2013, 12:14   #5  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ряд проблем можно снять созданием вьюшек. Понятно, их нужно перестраивать в случае чего. Но мне кажется, что с т.з. сокращения количества полей - вьюшка - будет "самое то". Нет?
Нет. Если ты в базовую таблицу засовываешь, допустим, 80 дополнительных полей, они (даже если там нет данных), будут занимать какое-то (пусть небольшое) место в записи. Чем больше средний размер записи, тем большее количество страниц должен прочитать сервер при извлечении данных.
Кроме того - если мы добавим совсем уж много полей в базовую таблицу, то дочерние индексы тоже надо будет по ней строить. Это слегка усилит накладняк на обновление (не во всех случаях, но, в общем, в каких-то случаях - может увеличить).
За это сообщение автора поблагодарили: sukhanchik (3).
Старый 04.03.2013, 11:59   #6  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Для того чтобы реализация механизма была идеальной, надо было бы просто добавить возможность в свойствах таблицы-наследника указывать место физического хранения ее полей - в отдельной таблице или в той же таблице что и поля родителя.
А смысл? Если физическое хранение полей в ней - то возвращаемся к тому, что было в АХ 2012 без R2. Т.е. с кучей джойнов.
Т.е. какой резон давать выбор? Опять-таки - я смотрю глазами практика, который не будет лишний раз заморачиваться с реализацией, если есть возможность не заморачиваться .
Что дадут джойны ? Даже в случае с LedgerJournalTrans, где такая архитектура может быть оправдана - там лишние джойны явно не приведут к увеличению производительности.
__________________
Возможно сделать все. Вопрос времени
Теги
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, время: 09:23.