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

[macklakov]

Цитата:

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

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие. То что можно отзеркалить, вообще не должно в этих таблицах находиться. Справочник адресов и справочник юр. лиц отдельные сделать и все. Никакой иерархии наследования. Никакого зеркалирования. Юр. лицо, это юр. лицо, независимо от того, поставщик это, клиент, сотрудник на контакте, субподрядчик по проекту или еще кто. Проводки и по поставщикам и по клиентам должны отражаться в ГК. Это общее. Но они совершенно по разному отражаются. Разная детализация, разный смысл. Платежи, как уже упоминал, совершенно по разному обрабатываются. Процесс разный, зачастую сопровождается разными документами. И поэтому вся эта иерархия CustVendOutPaym только под ногами путается.

[belugin]

Цитата:

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

А откуда этот вопрос проистекает? Где сказано что в бизнесе между этими процессами много общего? Ace of Database говорит что у него джобы зеркально выглядят. Но они зеркально выглядят потому, что в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего? Например, ко мне не может подойти начальник и сказать "испеки мне скорость и булочки с изюмом" просто потому, что для этих двуз понятий нет никакого общего смысла что-то делать. А вот для AR и AP возникла. Как так получается?

Цитата:

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

С совершенно разной структурой или они должны отличаться только данными?

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

[mazzy]

Цитата:

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

Между таблицами клиента и поставщика много общего, соответственно очень много одинаковой логики и она дублируется.

На самом деле не очень. А то реально общее - не полностью реализовано.
поставщики и клиенты - это контрагнеты.

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

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

контрагентов пытались получить на DirParty.
со всей вытекающей сложностью.

Цитата:

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

Чтобы избежать дублирования, изобрели Maps. Всю общую логику переместили в CustVend*. Очень элегантное решение, кстати.

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.
2. не всю )
3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Цитата:

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

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

но это действительно разные процессы.

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Цитата:

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

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

Чё это?
Зря ты принижаешь возможности начальника. ))))
Может конечно подойти и может сказать. Это твоя проблема как разработчика объяснить почему ты не будешь делать как начальник сказал ))))

Цитата:

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

То есть в одном справочнике есть юридический адрес, а в другом на этом месте табуретка?

да. у физика нет юридического адреса.

Цитата:

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

А вот для AR и AP возникла. Как так получается?
С совершенно разной структурой или они должны отличаться только данными?

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

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

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

а также сугубо технические операции типа сопоставления дебет-операций с кредит-операциями.

То есть структура сущностей имеет что-то общее, операции существенно разные так?

В каком смысле сопоставление "техническая" операция?

Цитата:

будем справедливы:
1. maps изобрели не чтобы избежать, а чтобы хоть как то работать с дублированием.

"Как-то работать" это и есть в каком-то смысле избежать. Например избежать дублирование кода который как-то работает.

Цитата:

3. не очень элегантное. в стандартном функционале постоянно приходится писать if/switch... методы map имеют чудовищный синтаксис и очень плохо используются.

Почему вообще возникает потребность делать общий код, если общего мало? Почему просто не продублировать?

Цитата:

люди на проектах часто делают врапперы типа такого
https://github.com/mazzy-ax/SysCustVend

Они все оверэнжиниры?

Цитата:

а нет такой потребности.
это просто техническое решение - сделать их похожими.

Только что выше ты сказал, что потребность есть. Все мепы и классы и прочее.

Цитата:

да. у физика нет юридического адреса.

Мы говорим о разнице между AR и AP а не физиками и лириками. В АR у юрика есть юр адрес, а в AP нет?

Цитата:

Собственно это и есть тема этой ветки:
Оver-engineering - "зачем так сложно?"

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

[mazzy]

Цитата:

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

То есть структура сущностей имеет что-то общее, операции существенно разные так?

перечитал выше. я вроде не употреблял слово "все" и его отрицание "ничего" )
что-то общее имеет. имеет и что-то различное.

Цитата:

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

В каком смысле сопоставление "техническая" операция?

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

Цитата:

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

"Как-то работать" это и есть в каком-то смысле избежать. Например избежать дублирование кода который как-то работает.

Макс, высказывание полностью на твоей совести.
Как скажешь.

Цитата:

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

Почему вообще возникает потребность делать общий код, если общего мало? Почему просто не продублировать?

Они все оверэнжиниры?

Как только возникает слово "ВСЕ" - жди логической ошибки.
Да, некоторые считают, что некоторые они - оверэнжиниры.

Цитата:

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

Только что выше ты сказал, что потребность есть. Все мепы и классы и прочее.

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

разница как между классом-потомками и интерфейсом-реализациями.

Цитата:

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

Мы говорим о разнице между AR и AP а не физиками и лириками. В АR у юрика есть юр адрес, а в AP нет?

я так и сказал - "не полностью реализовано".

Цитата:

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

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

Некоторые системы, например 1С, вводят понятие "контрагент"
а специфику сделки выносят в договор (там есть свои тараканы и есть свои минусы)

некоторые системы, например банковские, оперируют понятиями поставщик, а вместо клиентов могут быть разные типы аккаунтов - накопительные/текущие/карточные/валютные (там есть свои тараканы и есть свои минусы)

некоторые системы типа всяких CRM оперируют понятием "контакт". не со всеми типами контактов можно заключить договор (делать бизнес), а также не со всеми типами контактов можно контактировать (например, юр.лица - для них должны быть указаны контактные лица-люди)

Просто ДВА модуля/справочника с одинаковыми полями - это не единственное решение. Справочников/модулей может быть и больше, и меньше.

[macklakov]

Цитата:

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

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

Не, ну в принципе да, процесс один. Только есть один маленький нюанс

Цитата:

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

Вопрос такой: зачем вообще нужна потребность делато что-то одинаковое для закупок и заказов, если между ними нет ничего общего?

Очень хороший вопрос. Ведь эти модули естественным образом расползаются, один в Procurement and Sourcing, а другой в Sales and Marketing. В чем тогда сермяжная правда двуединства Accounts Receivable и Accounts Payable? Может в слове Accounts?

Цитата:

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

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

Ну иерархию в DirParty сделали ведь. Значит и скорость испечь сможете. Технически вы отборные специалисты, лучшие на рынке. Значит справитесь.

[ax_mct]

Цитата:

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

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

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

Общего - до фига. А дублировать код - не по жабьи.

[ta_and]

Цитата:

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

в системе Cust и Vend отзеркалены, а не потому что у бизнеса нужды такие.

Я очень долго думал о причине разделения таблиц CustTable и VendTable.
Никак не мог для себя понять. ЗАЧЕМ было разделять таблицу контрагентов на две независимые таблицы.
Единственное, что меня успокоило и более или менее оправдало это решение - это разграничение прав доступа.
Ведь в Ах ранних версий настроить права доступа по записям было на два порядка сложнее, чем разграничить права доступа к разным таблицам.
Видимо только поэтому родились Cust и Vend вместо Contragent.
Ну а после того, как родился этот уродец с одним телом, но двумя головами, пошла поехала вся даунутая родня уродского семейства CustVend.
И Мапы таблиц придумали не от хорошей жизни, а как раз из-за необходимости одеть одну шапочку одновременно на две головы. (я ничего не имею против Мапов самих по себе. Решение интерфейсов к таблицам идеальное)

[Pustik]

Цитата:

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

Я очень долго думал о причине разделения таблиц CustTable и VendTable.

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

[Raven Melancholic]

Цитата:

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

Несомненно свысока своего опыта мы понимаем, что было бы лучше, что хуже.

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

[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 делают отдельную, более денормализованную базу.