Оver-engineering - "зачем так сложно?"

[macklakov]

Цитата:

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

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

Доступ на уровне записей и сейчас лучше не использовать. Быстродействие убивает. Дело в другом. Дело именно в увлеченностью ООП.
ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно.
Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.
Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно.
Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

[Raven Melancholic]

Цитата:

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

Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться.

Точно, что для ERP главное это база данных? Разве не предметная область?
Когда я должен дать ответ по данным кассового чека, сколько покупатель может получить бонусов за эту покупку в зависимости от текущих акций, то какая разница получил ли я данные чека из базы, в которую он уже сохранен, получил ли этот чек прямым запросом из кассовой системы через Connector или получил его запросом через WEB сервис от консультанта торгового зала с планшета?

[ax_mct]

Цитата:

Сообщение от Raven Melancholic

...

Ответил в курилке.
Оver-engineering - "зачем так сложно?" - Мортира Карл

[macklakov]

Цитата:

Сообщение от Raven Melancholic

Точно, что для ERP главное это база данных? Разве не предметная область?

Предметная область в разы лучше реализуется всякими специализированными решениями. ERP обычно внедряют для того, чтобы повысить управляемость конторы в целом, а не для повышения эффективности операционистов (которого обычно не происходит). ERP это, своего рода, лекарство от болезней роста. Управляемость же достигается за счет консолидации информации, позволяющей строить разноплановую отчетность в реальном времени. Именно поэтому в маркетинге Dynamics такое значительное место занимает BI. Менеджмент хочет видеть что у них в конторе творится.
Т.е. если у на то пошло, то пляска идет даже не от базы, а от построителей отчетности. И я не знаю хороших построителей отчености по объектным базам данных, к примеру. А вот SAP, решили что им даже обычная RDB недостаточно, хороша, и потому запустили HANA.

[gl00mie]

Цитата:

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

ООП прекрасный подход для написания всяких фреймворков и системных вещей. К примеру, drag-n-drop, на ООП выглядит очень красиво, элегантно и просто. Но, в случае ERP, главное это база данных. Ради нее все делается и вокруг нее все должно строиться. Внедрять в бизнес-логику ООП, в то время как у тебя используется RDB, бессмысленно. Но в AX пошли именно по пути ООП, это очевидно по ряду признаков. В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу. И в случае CustVend, у нас такой таблицы нет. Т.е. пляска идет не от базы, а от ООП. И именно эта общая стратегия привела к появлению сперва Maps, а потом уже и наследования таблиц. Доминирует язык, а не база.

Что-то тема наследования таблиц никак не отпустит - давайте на минуту отвлечемся от нее. А как же журналы, которые есть в Аксапте с давних времен, когда и нормального ООП хотя бы с модификаторами доступа для методов в ней не было? Там тоже ООП не к месту? Может, надо было нашлепать по отдельной таблице на каждый тип журнала ГК и УЗ, а в разноске тупо копипастить общую логику?
А как же проводки в Управлении запасами, которые жили, не тужили в одном InventTrans'е, "обсчитываясь" двумя ортогональными иерархиями классов, реализующими всевозможные комбинации правил обновления статусов запасов с источниками этих обновлений? Там сколько разных таблиц надо было сделать, может, по одной на каждый источник (покупка, продажа, перенос, инвентаризация, списание в производство и т.п.)? А как надо было бы отвечать на вопрос, сколько товара на складе или откуда списать в резерв?..

Цитата:

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

Похоже что именно несовместимость парадигм программирования и движка базы данных и порождает столько сложностей. Т.е. по хорошему, надо или делать приличную схему данных и под нее перестраивать код, тогда все будет просто, понятно и быстро работать. Либо надо как SAP, делать под себя движок БД. Чтобы все эти программистские парадигмы имели прямое отражение в БД. Тогда, опять таки, все будет просто и надежно. Но т.к. MS привязал AX к флагманскому SQL, то вариантов остается не так много. Плясать надо от SQL. Но разработчики AX явно продолжают сосредотачиваться на ООП и на языке, а базу данных подстраивают под код. И именно это порождает технические проблемы, которые потом героически пытаются решить, с переменным успехом.

А для чего именно SAP замутил свою HANA, неужели для упрощения кода системы, а не для повышения производительности и масштабируемости? Разве не работал он десятилетиями на РБД сторонних производителей и разве не на этих РБД он завоевал свою долю рынка? Или, может, он свою долю рынка завоевал не благодаря РБД, а вопреки?..

Цитата:

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

Вот именно! Само понятие контрагента, т.е. счета второй стороны сделки, действительно общее для всех процессов. Причем общее с точки зрения бизнеса. А из-за того что такого понятия нет, в AX крайне поддерживать баланс контрагента крайне сложно.

Есть такое понятие - называется party, и справочник отдельный для всех-всех контрагентов есть. Если нормально связывать сущности из разных модулей (клиентов, поставщиков, сотрудников, etc) через party и строить отчеты вокруг нее, то всё получится. Только мне бизнес-пользователи почему-то рассказывали, что им и их контрагентам не интересен баланс "вообще", им интересен баланс в разрезе договоров и проч. И сопоставлять проводки "вообще" контрагенты не позволяют: платит, допустим, клиент за отгрузки и явным образом уточняет, что это вот за те две недельной давности, а не за три другие месячной давности. Удивительные люди...

Цитата:

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

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

А у вас это в системе должно быть отражено: кто чего, кому и в каком разрезе должен Надо консолидированно - крутите отчеты, а не заставляйте систему суммировать теплое с мягким. Потому что условия везде разные, и зачастую нельзя просто так схлопнуть дебиторку за аренду с кредиторкой за отгрузки или с выплатами дивидендов - регулирование, арбитраж, ответственность, условия везде разные. Если же вы для себя хотите таким образом данные схлопнуть - крутите отчеты вокруг party.

Цитата:

Сообщение от Raven Melancholic

Проблема даже не в том, что поставщик/клиент это разные справочники с разными таблицами отслеживания взаиморасчетов, потом объединенные в какие-то общие иерархии, мапы. Меня больше смущает подход, когда обработку платежей/начислений именно клиентов/поставщиков так объединили, а для остальных сделали отдельную обработку. Чем такая обработка для клиентов/поставщиков отличается от тех же действий с сотрудниками, с подотчетными лицами, с акционерами, с инвесторами и заемщиками, государством и т.п.?

Проклятое наследие прошлого Для модулей РСК и РСП были отгрузки и оплаты, было сопоставление проводок - вот кому-то и показалось, что можно выделить общую логику. Для модуля управления персоналом такого сопоставления не требовалось - вот и не выделили. А расчетов с акционерами, инвесторами и заемщиками исторически вроде и вовсе не было.

Цитата:

Сообщение от Raven Melancholic

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

Пока что общий подход выливается во что-нить вроде Source Document Framework

[macklakov]

Цитата:

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

крутите отчеты вокруг party.

это, кстати, как раз рождение в муках велосипеда под названием "контрагент". Просто люди никогда велосипеда не видели и не знают зачем нужны велосипеды. Поэтому инженерный процесс непростыми путями следует.

[belugin]

Цитата:

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

В ООП когда у тебя есть что-то общее, ты выделяешь класс-родитель, в структуре же данных ты выделяешь общее в отдельную таблицу.

Насколько я знаю, это зависит от свойств данных и типичных запросов http://www.agiledata.org/essays/mapp...ingInheritance

Инфологическая модель не обязана отражаться в физическую один в один

[macklakov]

Цитата:

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

Насколько я знаю, это зависит от свойств данных и типичных запросов http://www.agiledata.org/essays/mapp...ingInheritance

Так об том и речь, что "Mapping Objects to Relational Databases". Моя же точка зрения состоит в том, что более практично было бы делать mapping в другую сторону. Базу данных отражать в объекты. Просто потому, что конечной целью внедрения является отчетность. А отчетность берется из базы. А т.к. в качестве базы у нас, волевым усилием, назначен SQL, то вся суть разносок в том, чтобы заполнить таблицы, по которым удобно и быстро строить разноплановые отчеты.

Цитата:

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

А для чего именно SAP замутил свою HANA, неужели для упрощения кода системы, а не для повышения производительности и масштабируемости?

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

Цитата:

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

Только мне бизнес-пользователи почему-то рассказывали, что им и их контрагентам не интересен баланс "вообще", им интересен баланс в разрезе договоров и проч.

Ну так если вы в рамках отдельного договора работаете, то вам и стандартные Cust и Vend баллансы все равно не особо нужны. Смысл все это городить
С другой стороны, очень простой, жизненный, пример. Сотрудник покупает у родной конторы товар в счет будущей зарплаты...

Цитата:

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

Если же вы для себя хотите таким образом данные схлопнуть - крутите отчеты вокруг party.

Отчеты кручу не я, а команды BI или DW. А они просто рыдают при виде party и ledger.
Вот party это как раз яркий признак того, что люди не очень понимали что и зачем они делают. С одной стороны, это как раз логичная попытка создать единый справочник экономических субъектов. В другой стороны, мотивация его создания была чисто техническая, без привязки к бизнесу. Наворотили иерархию, а балланса-то и нет. Даже регистрационные данные туда не перенесли, они так и остались на Cust и Vend. Т.е. лучше чем ничего, но попотеть приходится.

Цитата:

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

А как же проводки в Управлении запасами, которые жили, не тужили в одном InventTrans'е, "обсчитываясь" двумя ортогональными иерархиями классов, реализующими всевозможные комбинации правил обновления статусов запасов с источниками этих обновлений? Там сколько разных таблиц надо было сделать, может, по одной на каждый источник (покупка, продажа, перенос, инвентаризация, списание в производство и т.п.)?

Да, по логике CustVend так и выходит. Раскидать InventTrans на несколько таблиц, но некоторые из них покрыть иерархией объектов (ибо како-то сходство наблюдается), а остальные оставить сами по себе т.к. сходства не заметили или руки не дошли. А кому надо консолидированно наличие на складе посмотреть, пусть пользуют DirInventory

[belugin]

Цитата:

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

Так об том и речь, что "Mapping Objects to Relational Databases". Моя же точка зрения состоит в том, что более практично было бы делать mapping в другую сторону. Базу данных отражать в объекты.

Почитайте что там внутри объектовые свойства не используются те же рассуждения применимы при проектировании физической модели где нет наследования по логической где есть.

[BIDeveloper]

Цитата:

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

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

Не так все просто ) Для ERP ещё важно, чтобы одновременно сотни/тысячи пользователей могли вставлять/обновлять быстро и без блокировок множество записей. И для этого как раз лучше подходит более нормализованная модель. То, что в Аксапте кубы настраивались прямо на рабочую базу - это исключение из правила ) Обычно для dwh делают отдельную, более денормализованную базу.

[macklakov]

Цитата:

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

И для этого как раз лучше подходит более нормализованная модель.

Ну и по какой форме у нас нынче DirParty нормализована?

[EVGL]

Цитата:

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

Вот party это как раз яркий признак того, что люди не очень понимали что и зачем они делают. С одной стороны, это как раз логичная попытка создать единый справочник экономических субъектов. В другой стороны, мотивация его создания была чисто техническая, без привязки к бизнесу. Наворотили иерархию, а балланса-то и нет. Даже регистрационные данные туда не перенесли, они так и остались на Cust и Vend. Т.е. лучше чем ничего, но попотеть приходится.

Нет, протестую. На одном проекте на AX2009 по требованию клиента (международный концерн) пришлось шагнуть еще дальше чем DirParty-2017, а именно ввести компанейно-зависимую роль адреса. Когда один multinational поставляет другому multinational, и дело происходит в Европе, где 2 столицы находятся на расстоянии 60 км, то одного и того же клиента могут обслуживать несколько юрлиц концерна, которые еще и состоят во внутрихолдинговых отношениях друг с другом. Возникает проблема синхронизации справочников между компаниями и даже автоматического перевода названия города с одного языка на другой как в AX7. Регистрационные данные, кстати, теперь частично перенесли, но непрактично (пытался объяснить PM'ам в московском центре разработки, почему, но был не понят).

[macklakov]

Цитата:

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

Нет, протестую.

Не понял, протестуешь против возможности посмотреть общий баланс по контрагенту?

[EVGL]

Цитата:

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

Не понял, протестуешь против возможности посмотреть общий баланс по контрагенту?

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

[macklakov]

Цитата:

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

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

Значит я неправильно донес мысль. Что DirParty выделили это хорошо и правильно. Но то как ее реализовали, вызывает сомнения в том, что присутствовало отчетливое понимание.