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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.02.2018, 00:49   #1  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Table extension
И снова я прошу поделиться опытом о том, как делается у вас на проекте. На этот раз про добавление новых полей в стандартные таблицы.
На предыдущих моих Ax2012 проектах добавлялись в стандартные таблицы. Проблем не имели. Сейчас новый проект начинаем(да, снова на Ax2012 - это выбор клиента, не обсуждается)

Заранее спланировать сколько полей будет куда добавляться не реально.
Нужно решить добавлять их в стандартные таблицы или создавать новые. (вроде как, основная рекоммендация от мс, что, если больше 5, то надо создавать отдельную таблицу)

Посмотрела видео https://www.youtube.com/watch?v=YrfHtAKRMbk и ужаснулась. Особенно неприятен вопрос с производительностью. Столько уродливых чертыханий, а в итоге лишние джойны, перекрытие insert(), не использование кластерного индекса(большинство стд таблиц не по recid кластерный имеют). Да еще лишние потенциальные баги

Особенно насторожил комментарий в конце этой статьи http://daxonline.org/9-table-extension-framework.html о том, что у товарищей были проблемы при использовании document services. Тк у нас будет много интеграций впереди, то самое неприятное было бы напороться на подобные проблемы, когда основной функционал уже разработан и протестирован.

Успокойте барышню, cкажите, что все хорошо, и стоит следовать политике партии и в этом случае, а?

Спасибо

AX2012 R3
Старый 24.02.2018, 06:36   #2  
ta_and is offline
ta_and
Участник
 
192 / 114 (4) +++++
Регистрация: 26.02.2002
Адрес: СПб
Мой личный подход:
Не надо плодить лишние сущности без необходимости.
Если нет особых требований, то добавляю поля в нужную таблицу и не парюсь.
Особые требования для выделения отдельных таблиц:
1. Желание клиента. Против не попрешь.
2. Информация в дополнительных полях будет заполняться не для всех записей существующей таблицы и необходимо экономить место в базе данных.
3. Есть вероятность распараллеливания данных по одной записи существующей таблицы (несколько дополнительных строк например с историей изменений)
За это сообщение автора поблагодарили: sukhanchik (2), axotnik88 (1), alex55 (1).
Старый 24.02.2018, 10:08   #3  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
543 / 559 (20) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Я бы добавлял поля и не парился. Новую таблицу нужно добавлять когда нужна таблица. Не забывайте эту систему будут внедрять и сопровождать другие люди и они могут не понять ваших гениальных замыслов
Ну и 12ку я бы больше не внедрял
Старый 24.02.2018, 10:25   #4  
DAX.Company is offline
DAX.Company
Участник
 
294 / 97 (4) ++++
Регистрация: 24.11.2016
Просто добавляйте поля. В стандарте не так уж много крупных таблиц с расширением (номенклатура, продажи, покупки, персонал, договора, журналы). На них итак уже есть подходящее вам расширение (_RU, например). Не думаю, что будут у вас еще какие то таблицы где надо будет добавлять больше 30 полей.
Старый 24.02.2018, 10:31   #5  
DAX.Company is offline
DAX.Company
Участник
 
294 / 97 (4) ++++
Регистрация: 24.11.2016
Цитата:
Сообщение от skuull Посмотреть сообщение
Ну и 12ку я бы больше не внедрял
Присоединяюсь.
Старый 24.02.2018, 11:28   #6  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,401 / 887 (32) +++++++
Регистрация: 13.01.2004
"Во первых строках" видо, на которое указана ссылка было сказано, что данный функционал (предположительно) был создан для поддержания локализации. Далее в том же видео об этом говорится отдельно и особо.

Т.е. если посмотреть, в каких случаях часть полей таблицы в стандартном FrameWork были выделены в отдельную таблицу без "оправдания" в виде структуры данных или бизнес-логики, то это все таблицы-локализации. С окончаниями, вроде RU, BR, UK, PL и т.п., которые явно указывают на страну. Локализацию

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

Просто в младших версиях Axapta эта задача решалась при помощи конфигурационных ключей, которые меняли структуру данных "на лету". А в Ax2012 для этого предлагают CountryRegionsXXX, поскольку он дает больше "свободы маневра"

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

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

PS: Хотя сильно подозреваю, что в старших версиях ситуация изменится на прямо противоположную. Уж больно удобный способ "не трогать" хотя бы структуру стандартных таблиц. Но это дело будущих версий
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 24.02.2018, 11:36   #7  
sukhanchik is offline
sukhanchik
Moderator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,650 / 2141 (77) +++++++++
Регистрация: 13.06.2004
Адрес: Москва
Желание клиента внедрять AX2012 вполне здравое и я его поддерживаю. Любая компания, которая хочет получить инструмент для работы - хочет получить готовый инструмент, в котором уже наиболее известные баги вылечены. D365 сейчас все же еще далека от совершенства (с т.з. готового инструмента), особенно если требуется использование российской локализации.
К слову сказать, что со стороны внедренца, конечно лучше внедрять D365 - это и развитие себя и возможность повлиять на исправление багов в МС.

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

Рекомендации Микрософт, как и бест практис надо всегда пропускать через призму разума. Когда выходила RTM-версия - было много рекомендаций про наследование таблиц - про то, что это круто и это надо использовать. А позже как-то все это стушевалось и в рекомендациях разработки одного из партнеров была даже фраза, что наследование стараться не использовать. В Микрософте бывают рекомендации, которые противоречат производительности и удобству поддержки. В моей практике помню мы так отчет ДДС правили путем влезания в разноску, а не собирания его, как это делается штатными средствами, потому что было требование заказчика обеспечить скорость его построения в 1 минуту.
Были еще рекомендации (в старых версиях) по экспорту / импорту данных через группу определений. Опять-таки это все работает до определенного объема данных.

Заранее все не предусмотришь, поэтому я бы добавлял поля, а потом, если это стало бы краеугольным камнем в производительности - оптимизировал бы код и не факт что это было бы просто вынос полей в отдельную таблицу.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 24.02.2018 в 16:26.
За это сообщение автора поблагодарили: Logger (3), IKA (1).
Старый 24.02.2018, 22:13   #8  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,228 / 2421 (89) +++++++++
Регистрация: 16.01.2004
Адрес: Москва
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Т.е. если посмотреть, в каких случаях часть полей таблицы в стандартном FrameWork были выделены в отдельную таблицу без "оправдания" в виде структуры данных или бизнес-логики, то это все таблицы-локализации. С окончаниями, вроде RU, BR, UK, PL и т.п., которые явно указывают на страну.
Все верно. До Ax2012 все локализации взаимно друг друга исключали - они были в слоях GLS и их нельзя было поставить на одну установку. То есть multinationals - компании с юридичекими лицами в разных странах - не могли сосуществовать на одной установке AX.

В 2012 все слои были слиты в один. НО получилось так что
  • результирующие таблицы стали гигантскими и АОС стал ругаться "увлеичьте мне буфер"
  • Не было уверенности, что при каких-то действиях на компании принадлежащей одной стране не будет каких-то негативных эффектов от функционала в другой стране

Чтобы это преодолеть локализация была вынесена в отдельные таблички и в отдельные ifы, проверяющие код страны.
__________________
https://axcoder.github.io
Старый 25.02.2018, 11:22   #9  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
2 sukhanchik: Меткая параллель с былыми рекоммендациями про виртуальные таблицы. Тоже концептуально все было как бы логично, а на практике в реалиях аксапты - корявое чудовище


Ситуация ясна.
Всем большое спасибо!
Старый 26.02.2018, 12:27   #10  
IKA is offline
IKA
Участник
 
359 / 65 (3) ++++
Регистрация: 15.03.2006
Глупость написала, и никто из вежливости не поправил ... Не "виртуальных", а "наследование таблиц" имела ввиду , конечно ..
Теги
ax2012, как правильно

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
stoneridgesoftware: Extension Model: Creating a Static Table Method in Dynamics 365 for Operations Blog bot DAX Blogs 0 08.06.2017 21:11
organicax: Simple table extension to add a new field. Blog bot DAX Blogs 0 01.02.2017 05:22
sashanazarov: Table extension framework Blog bot DAX Blogs 0 20.10.2015 13:11
msdyncomm: Microsoft Dynamics CRM 2013 Setup and Upgrade New Features - Base and Extension Table Merge Blog bot DAX Blogs 0 05.11.2013 08:11
PatrickChua: Temporary table Blog bot DAX Blogs 0 28.10.2006 18:14
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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