Infor - так теперь принято кодить или лажа?

dabino
Дата: 31.08.2013 02:44:33
У меня необычный вопрос. Я уже 12 лет не занимаюсь программированием, но "есть IT background". Волею судеб столкнулся с внедрением ERP Infor на производственном предприятии (БД - Oracle), и недавно дошли руки посмотреть код, которым это все реализовано.
Просто приведу несколько примеров того, что у меня вызывает удивление:
- процедуры построения отчетов не используют возможности sql (типа join). Вместо этого есть код, который вытаскивает из базы селекты, а потом в цикле обрабатывает их, каждый раз вызывая новые запросы.
- отчет генерируется в файл excel (типа xlsx, xml представление). Но! Нет общей функции выгрузки в файл, в каждой функции своя реализация, все xml тэги перемешиваются с данными прямо в коде.
- везде в коде - сокращения, нечитаемые названия переменных и полей таблиц
- есть "магические числа" - просто стоят в коде, не объявляются как константы
- в самой базе oracle - только таблицы, вьюшки вообще не используются
- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл)
Я понимаю, что я много пропустил в индустрии, есть application server, где вся бизнес логика крутится. Но так что, действительно принято писать теперь код? Или я немного прав, и проект делали низкопоофессиональные консультанты?
instant
Дата: 31.08.2013 10:53:29
dabino
Я понимаю, что я много пропустил в индустрии, есть application server, где вся бизнес логика крутится. Но так что, действительно принято писать теперь код? Или я немного прав, и проект делали низкопоофессиональные консультанты?

Вам нужно в раздел "Программированиие", здесь все же вопросы кодирования не сильно обсуждаются.
Shuhard
Дата: 31.08.2013 16:37:15
dabino
Но так что, действительно принято писать теперь код? ?

код коду рознь,
для ERP описанная ситуация типична, от 1С до SAP
foxwizard
Дата: 02.09.2013 07:42:33
dabino
- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл)

За такое в нормальной компании - увольнение....
s_ustinov
Дата: 02.09.2013 11:56:40
foxwizard
dabino
- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл)

За такое в нормальной компании - увольнение....


за откаты в нормальной компании - тем более увольнение.
какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний?
Shuhard
Дата: 02.09.2013 13:30:47
s_ustinov
за откаты в нормальной компании - тем более увольнение.
какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний?

процентов 10-15
s_ustinov
Дата: 02.09.2013 13:45:25
Shuhard
s_ustinov
за откаты в нормальной компании - тем более увольнение.
какой процент договоров на внедрение заключается без откатов? или, другими словами - какой процент нормальных компаний?

процентов 10-15

отож
хотя я наверно больше верю в людей и обычно называю цифру "до 20%"
учитывая, что "нормальных" клиентов максимум один из пяти - о каком качестве (продуктов, консультантов, результатов проектов в целом) можно говорить?
Izya
Дата: 02.09.2013 19:51:16
foxwizard
dabino
- ну и в результате отчеты генерятая часами, потом пользователи дообрабатывают их в экселе (если удается открыть файл)

За такое в нормальной компании - увольнение....

По некоторым пунктам нормальность компании ваще не при чем. Скажем так - по основным пунктам. Например, использование констант в коде на скорость не влияет, так же как и нечитаемость имен. А все остальное - в основном проблемы архитектуры и языковых средств, реализованных в ERP.

Вообще (это моя точка зрения), ERP возникли как средство автоматизации бизнеса. Но очень скоро до производителей дошло, что одними настройками (галочками в формах) не обойтись, стали придумывать свои языки. Я даже не говорю про уровень языков и сред программирования... с содроганием вспоминаю C-AL(интересно, с 4-й версии что-нибудь в лучшу сторону поменялось?). Проблема в том, что этит языки она делали на своем уровне, вне СУБД. Ну и возникло деление по уровням. которое преподносится как типа круто (и местами оно может так и есть, например, говорят, что, вроде, масштабировать легче). Но КМК это ведет в тем проблемам, про которые тут написано, и проблем больше чем преимуществ.

Очень много маркетинга. Одной конторе втюхали тот же нафижн со словами, что де отчеты в Excel так же просто выводить, как в Access'e, и ваще - это тот же ассесс адаптированый под бизнес . А по факту , для каждого отчета надо отдельный выводить в Excel прописывать со всеми навижнскими танцами. Но даже если бы Навик был бы так же удобен как среда VBA , то от принципиальных проблем, связанных с разделением по уровням, это не избавит.
George Nordic
Дата: 03.09.2013 09:38:46
ТС говорит про "Infor" и "Производственное предприятие", следовательно это Infor LN. Я бы посоветовал прочитать про BAAN и его историю. Описываемые ТС проблемы характерны для БД-независимых учетных систем. Возможно, со временем остался только Oracle, как в том же NAV / DAX - только MS SQL.

С Уважением,
Георгий
LSV
Дата: 03.09.2013 11:46:44
Описываемые ТС проблемы характерны для БД-независимых учетных систем. Возможно, со временем остался только Oracle, как в том же NAV / DAX - только MS SQL.
Увы, это не решает сабжевых проблем, т.к. все равно подход остается навигационным (ставим фильтр, считываем запись, перебираем до конца + куча вычислений и навигаций).
Проблема отчасти решится, когда вычисления будут только на сервере и только на родном SQL и на оптимальной структуре таблиц/полей. :)

Удивление ТСа непонятно. Для него это открытие ? :)