авторВ OeBS же все разработки ведутся на PL/SQLдаже спорить не буду. я видел этот код, я видел консультантов, считающих нормальным ковырять ядро на pl/sql. я не буду упоминать, что логика на pl/sql требует лицензирования кластерного софта там, где нормальные системы обходятся дешевыми апп-серверами и NLB. я не буду говорить, что через веб интерфейс вы никогда не обработаете заказ из 30 позиций (при общей базе 100000 SKU) за 1 минуту

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

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

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

до уровня САП ей ползти еще долгооткройте секрет, что за уровень такой у сап-а? мой многолетний опыт работы с ним говорит, что это совершенно убогая в архитектурном плане платформа, с прикладным уровнем, застывшим где-то в 70-х годах

Proforgзачем заменять 4gl на язык более низкого уровнявсе эти уровни -- я не понимаю. я зато наверняка знаю, что и на 1С, и на .net C# я сделаю абап по скорости разработки и качеству решения

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

если уж про модули, то подавляющее большинство идет не дальше SD/MM/FI/CO, некоторые просто ограничиваются или FI, или CO. каждый модуль - сам по себе, никакой интеграции. данные нужно перегружать (в широком смысле) из модуля в модуль, явно устанавливать связи (причем далеко не всегда их можно установить)

масштабируемость - это единственное преимущество. все остальное - якорь, тяжелый балласт

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

asdfghjkl;Про фрагментарно - спору нет, а вот нащёт игнорируют - недопонял?они друг друга игнорируют: в транзакциях не используются бапи, а бапи не используют транзакции. две (иногда больше, мой любимый пример - формирование ОМа) независимые ветки

Сильно удивляет, что 1с и шарп в одном ряду стоят. Хотя как раз 1с и абап - одного поля ягоды. Если абап не знать, то вполне логично, что разработка займет больше времени. речь идет исключительно о написании кода: с какой скоростью и с каким качеством. абап сам по себе так себе в смысле языковых конструкций, но среда разработки - это вообще за гранью добра и зла.

в целом ничего конструктивного от вас я не услышал. давайте дальше. всю архитектуру достаточно условно я разобью на уровни: системный (потоки, файлы, семафоры, доступ к БД, транзакции), прикладная платформа (сказанное выше относится к этому уровню), прикладной (конкретный функционал: дебиторы, главная книга, ппм и т.д.)

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

в самом худшем случае это выглядит так:
* вы создаете объект
* он получает номер
* вы делаете commit work
* что-то прописывается в буфера и вам возвращается управление. никакого коммита в базу пока еще нет!!!
* изменения БЛОБом записываются в таблицу vbdata
* отдельный процесс из vbdata распихивает данные по нужным табличкам
* только теперь ваш процесс может работать дальше, будучи уверенным, что все остальные вызываемые им же (в том же потоке!) ФМ-ы увидят его изменения. и никакого способа узнать, когда же наступит этот счастливый момент

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

за сим откланиваюсь, вернусь позжее

iscrafmНепонятно зачем ты сюда приплел 1С, особенно в контектсте работы с СУБД, блокировками и внешними интерфейсами..., т.е. то, о чем лучше не вспоминать без необходимости. Перед возвращением почитай множество текстов на эту тему, чтобы не повторяться.
нижайше прошу мне не тыкать
про тексты - обязательно почитаю. что посоветуете?
про блокировки - не могу не вспоминать, с сапом это приходится хавать каждый день, как я тут уже говорил