Table extension

[IKA]

И снова я прошу поделиться опытом о том, как делается у вас на проекте. На этот раз про добавление новых полей в стандартные таблицы.
На предыдущих моих 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

[ta_and]

Мой личный подход:
Не надо плодить лишние сущности без необходимости.
Если нет особых требований, то добавляю поля в нужную таблицу и не парюсь.
Особые требования для выделения отдельных таблиц:
1. Желание клиента. Против не попрешь.
2. Информация в дополнительных полях будет заполняться не для всех записей существующей таблицы и необходимо экономить место в базе данных.
3. Есть вероятность распараллеливания данных по одной записи существующей таблицы (несколько дополнительных строк например с историей изменений)

[skuull]

Я бы добавлял поля и не парился. Новую таблицу нужно добавлять когда нужна таблица. Не забывайте эту систему будут внедрять и сопровождать другие люди и они могут не понять ваших гениальных замыслов
Ну и 12ку я бы больше не внедрял

[DAX.Company]

Просто добавляйте поля. В стандарте не так уж много крупных таблиц с расширением (номенклатура, продажи, покупки, персонал, договора, журналы). На них итак уже есть подходящее вам расширение (_RU, например). Не думаю, что будут у вас еще какие то таблицы где надо будет добавлять больше 30 полей.

[DAX.Company]

Цитата:

Сообщение от skuull

Ну и 12ку я бы больше не внедрял

Присоединяюсь.

[Владимир Максимов]

"Во первых строках" видо, на которое указана ссылка было сказано, что данный функционал (предположительно) был создан для поддержания локализации. Далее в том же видео об этом говорится отдельно и особо.

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

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

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

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

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

PS: Хотя сильно подозреваю, что в старших версиях ситуация изменится на прямо противоположную. Уж больно удобный способ "не трогать" хотя бы структуру стандартных таблиц. Но это дело будущих версий

[sukhanchik]

Желание клиента внедрять AX2012 вполне здравое и я его поддерживаю. Любая компания, которая хочет получить инструмент для работы - хочет получить готовый инструмент, в котором уже наиболее известные баги вылечены. D365 сейчас все же еще далека от совершенства (с т.з. готового инструмента), особенно если требуется использование российской локализации.
К слову сказать, что со стороны внедренца, конечно лучше внедрять D365 - это и развитие себя и возможность повлиять на исправление багов в МС.

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

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

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

[belugin]

Цитата:

Сообщение от Владимир Максимов

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

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

В 2012 все слои были слиты в один. НО получилось так что

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

Чтобы это преодолеть локализация была вынесена в отдельные таблички и в отдельные ifы, проверяющие код страны.

[IKA]

2 sukhanchik: Меткая параллель с былыми рекоммендациями про виртуальные таблицы. Тоже концептуально все было как бы логично, а на практике в реалиях аксапты - корявое чудовище


Ситуация ясна.
Всем большое спасибо!

[IKA]

Глупость написала, и никто из вежливости не поправил ... Не "виртуальных", а "наследование таблиц" имела ввиду , конечно ..