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

[EVGL]

Цитата:

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

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

Не отличается. Вы уж извините за подотчетных лиц, грехи молодости, а нынешнее поколении локализаторов никак не вырежет их нафиг. В стандарте сотрудника можно ассоциировать с поставщиком и оплачивать за один проход. На текущем проекте сделал так, чтобы запись в таблице поставщиков создавалась автоматически, а синхронизация имени идет через ГАК. Аналогично, по государству = налоговому органу автоматически формируется задолженность в РсП.

Однако, задачи модулей РсП и РсК отличаются: в одном случае есть задача платить как можно позднее (все это казначейство, бюджеты и тп) а в другом - получить деньги как можно быстрее (инкассо, collections, cash flow). Поэтому смотреть на это как на одну сущность - это упрощение.

[George Nordic]

Угу, тем более что контрагент может быть одновременно и поставщиком, и покупателем.

С Уважением,
Георгий

[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

[macklakov]

Цитата:

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

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

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

[belugin]

Цитата:

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

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

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

[BIDeveloper]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[ax_mct]

У меня сейчас одна из задач в AX2012 обеспечить установку primary vendor на уровне site в разрезе customer/customer group.

ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().

ООП надо чтобы salesLineType.getPrimaryVendor() то есть расширение конкретной функциональности, а не затем чтобы переставлять технический код местами чтобы расчлененка была более кровавой.
При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.

[belugin]

Цитата:

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

ООП вроде бы крутое везде и всюду с наследованием контрактов и прочим, а мне надо искать и заменять все вхождения inventTable.PrimaryVendor на что-то типа salesLine.getPrimaryVendor().

Это значит, что не всюду вот в этом конкретном месте (в таблицах) нет инкапсуляции.

[EVGL]

Цитата:

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

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

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

[macklakov]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

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

[Morpheus]

Цитата:

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

То есть пользы от ООП в АX я не вижу, только вред.

Методы, содержащие по несколько тысяч строк, написаны разделяющими Ваше мнение людьми.

[macklakov]

Цитата:

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

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

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

[dech]

Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне. У меня когда-то лет 7 назад была идея, а что если у таблиц сделать наследование полей, как в ООП... начал ковырять и пришел к нормализации таблицы :-)

[dech]

Цитата:

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

При этом если бы не было в системе ООП вообще а было что-то типа процедурно getPrimaryVendor_SalesLine(salesLine) то я бы не плакал. И клиент не рыдал

То есть пользы от ООП в АX я не вижу, только вред.

Технически код

vendor = salesLine.getPrimaryVendor();

трактуется компилятором так:

vendor = SalesLine::getPrimaryVendor(salesLine);

где SalesLine тупо работает как scope, т.е. область видимости, а salesLine - табличная переменная.
сам метод интерпретируется как

public VendTable getPrimaryVendor(SalesLine _salesLine)
{
;
    this = _salesLine;
    ...
}

Работа с this происходит неявно и нам удобнее работать с меньшим числом параметров. Но дело не в этом.
ООП предназначено для другого: наследование, инкапсуляция и полиморфизм. Не будь наследования, мы бы погрязли в дублировании кода. Полиморфизм позволяет работать с базовым классом, и не держать руку на пульсе, каждый раз спрашивая себя, а с функцией какой сущности (то бишь класса) я работаю?
Вот инкапсуляция - это да, она конкретно не доработана. Очень не хватает свойств, хотя методы доступа get/set/parm есть, но с ними не так удобно.

[Vadik]

Цитата:

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

Если подумать, то и наследование таблиц - также over-engineering. При нормализации таблиц уже до 3-й формы наследование излишне

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

[dech]

Цитата:

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

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

Я бы посмотрел в сторону View, но они в аксапте как-то не очень активно используются, например по сравнению с WEB-системами. Если глянуть тот же Wordperss или Drupal, там вьюхи используются чуть ли не чаще, чем сами таблицы. Да и поддержка на уровне БД. Тем более, что обычно нужны не все поля, а некоторый набор. Другое дело, когда на разные нужды требуются разные наборы полей.

[fed]

По моему, главная проблема с наследованием таблиц в Ax - это решение о том что родитель содержит в себе все поля всех наследников. Из за этого им пришлось в ранних версиях автоматически делать outer join родителя ко всем наследникам, а в поздних версиях - просто складывать все поля наследников в одну большую таблицу-родителя.
В классической системе мэппинга объектных отношений в реляционную БД, обращение к таблице наследнику, неявно делает inner join с таблицей родителем. В обращение к родителю ни к каким автоматическим join не приводит. Из за того что MS решил пойти своим путем, использование наследования привело к большому оверхиду - либо из за джойнов, либо из за тучи неиспользуемых полей в таблице.