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

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