DAX 2009: Ledger Table открывается медленно

[Evgeniy2020]

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

ваша задача настроить фонтан (сконфигурировать) так чтобы на поверхности
фонтан выдавал необходимую картинку во времени узор, струи, и т.д.

а большая часть всего скрыта под землей. Вот приходит новый человек и начинает изучать вентили (настройки) и то как это влияет на картинку на поверхности. а при выходе новых версий тоже приходится все изучать.
много вещей путем научного тыка. или огромные книжки читать.
вот тут и нужна что то вроде АОТ для аналитиков. динамическая функциональная карта и как то представлять код в наглядном виде в с привязкой с областям. чтобы сразу было бы видно. наверно какое то трехмерное отображение кода и областей функциональных. а то книжки сложно по 1000 страниц осиливать

[fed]

Хочу заметить, что в системе есть достаточно много функциональности (в том числе, написанной и отцами-основателями в Дамгаардовские времена), которая не несет никакой фундаментальной ценности и не всегда была так уж хорошо продумана. Соответственно - я могу понять смысл разбирательства в работе сводного планирования или закрытия склада или налогового модуля. Но я не вижу смысла каждый раз копаться в коде или методом проб и ошибок изучать каждую галочку и странность в системе. Как говорил один мой приятель:"Вот сидишь-сидишь, разбираешься-разбираешься, а потом все равно оказывается что оно никуда не годиться и проще свое написать, чем стандарт подправить".
Знание стандартной функциональности - это не цель, а средство. И я не вижу смысла прикладывать какие-то экстраординарные усилия для того чтобы выучить всю функциональность. Если ты некоторые базовые вещи по архитектуре системы понимаешь (и достигается это понимание ТОЛЬКО большим практическим опытом внедрений, а не экспериментами с галочками), то при попытке сделать свою функциональность, ты, скорее всего, полезешь в правильное место в коде и обнаружишь там что нужная функциональность уже написана, просто она зависит от галочки, которую ты пока не знаешь.

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

[glibs]

Интересно, а в SAP тоже такая тенденция есть... не вникать в параметры, а делать свое...

Или Аксапта меняет класс ПО с ERP системы на среду разработки.

[fed]

Просто небольшая доработка, по TCO часто оказывается дешевле и менее рискованной, чем изучение всех настроек с попыткой построить пользователей под эти настройки...
Задача-то не в том чтобы поменьше разрабатывать, а в том чтобы систему внедрить с минимальными затратами.
Кстати - в САПе эта тенденция есть еще в большей степени, потому что он сложный, и там незнание большей части функциональности консультантом - норма жизни.

[Ivanhoe]

Цитата:

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

Задача-то не в том чтобы поменьше разрабатывать, а в том чтобы систему внедрить с минимальными затратами

Обычно да, но пару раз реально работал с клиентами, которые честно пытались снизить количество доработок до минимума в т.ч. с точки зрения дальнейшей поддержки и обновлений от МС. Компании западные

[fed]

Цитата:

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

Обычно да, но пару раз реально работал с клиентами, которые честно пытались снизить количество доработок до минимума в т.ч. с точки зрения дальнейшей поддержки и обновлений от МС. Компании западные

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

[glibs]

Мое мнение — отсутствие нужной книжки — это отмазка.

При желании можно погуглить. И на данном форуме, и на многочисленных блогах сейчас уже много информации по системе. Но сначала нужно ткнуться в систему, найти что-то непонятное.

В конце концов можно вопрос тут задать. Глядишь и на форуме станет интереснее. А то скукотища. Только по разработке вопросы и остались. А коллективный разум — великая сила. Сам периодически что-то новое для себя узнаю и очень ценю форум за это.