Егоров АлександрТогда изменение БЛ вообще не потребует никаких ихменений кода системы, перекомпиляции и перетестирования.Может я чего не понимаю. Но как вы гарантируете работоспособность системы БЕЗ юнит-тестирования внесенных изменений? Допустим ваше изменение затронуло только BPEL. Как вы проверили что для заданных условий новая BPEL-логика дает правильный ответ?
Егоров АлександрСтоп-стоп-стоп. Уровень СУБД ведь проектирует тоже автор системы, в Вашем случае - это либо Вы, либо Ваща система нагенерила этих извраты в СУБД. :) Либо давайте пример, как работает "практически страндартная весчь". На примере: справочник контрагентов с полями ИНН, ЮрАдрес и Телефоны. Одному клиенту аудит не нужен. В Вашей системе он и не закладывался. У другого - требование "Справочник Контрагенты должен обеспечить хранение предыдущих значений реквизитов и автора изменений"? Ваши действия в Вашей системе?подключаю к проекту Hibernate Envers, на сущьность "Справочник Контрагенты" ставлю @Audited, делаю перехватчик и в нем заполняю поле "кто сделал изменение".

Компайл, коммит на сервер, автоматическая сборка и проверка юнитами.

Егоров АлександрЯ сижу не только на СУБД, но и на УЖЕ РАБОТАЮЩЕЙ СИСТЕМЕ. Если в этой системе требуется какое-либо изменение - я обращусь к автору этой системы, а не будут покупать новую. :) При замене же системы, пускай даже системы учета - затарты на приобретение новой СУБД далеко не самые главные. Причем чем крупнее фирма, тем больше затрат ложится на "дописание бизнес-логики", переобучение пользователей и перенастройку процессов, чем на стоимость СУБД. так ко мне и обратишься клиенты не переходят на другие СУБД ибо это дорого отнюдь не потому что нужно купить лицензий. Нужно еще обучить админов и т.п.

Егоров АлександрДа зарабатывайте, пожалуйста. Я же не мешаю. :) Единственное пожелание - не закрывайте полностью уровень БД от доработки на местах. А то потом DBA мучаются с тормозами, а ничего поделать не могут. ;)возможность доработки приложения компанией-заказчиком это либо если ПО изначально OpenSource либо стоит НАМНОГО дороже обычной лицензии. Чаще всего заказчик не хочет платить за возможность доработки ПО своими разрабами.

Егоров АлександрVoDAКак раз на начальной стадии пока система не выведена в продакшен - на юнит-тесты можно забить. Они замедляют процесс разработки. У меня накопилась обратная статистика. Сборка готовой системы из оттестированных модулей поисходит намного быстрее. Модификация модулей происходит чаще и чаще требует тестирования именно на этапе проработки архитектуры, когда каркас системы еще окончательно не определен. тут полное согласие. я говорю что модули быстрее делать без юнитов, а вы что полностью систему быстрее собрать если модули - готовы и сделаны юниты. Согласен, это именно так.

Егоров АлександрВот в этом у нас принципиальное непонимание. Любое изменение БЛ не должно требовать вообще изменения кода системы. Иначе это неправильная система. Или прикажете ходить на внедрение со средой разработки, отладчиками и тестироващиками?А какое изменение БЛ может быть в момент внедрения? В момент внедрения любые изменения БЛ уже завершены и заказчик получает результат. Если требуются еще изменения БЛ, то идет новый контракт и новая разработка + новое внедрение.

Егоров АлександрVoDAТак вынос БЛ в отдельный слой (на апп-сервер) и есть архитектурное решение.
...имеющие минусы в быстройдетсвии перед решениями, позволяющими оптимально "размазывать" БЛ по раздельным слоям. Но почему-то эти минусы очень фанатично отрицаются.минусов в быстродействии SQL - нет ибо Java выдает тот же SQL, что и ХП. Разница в скорости только в случаях массовой обработки данных БЕЗ сложной логики. Тут согласен

Вот только оптимальное "размазывание" логики по слоям чаще всего дороже в разработке, чем плюхнуть всю БЛ на АппСервер. И заказчик и разработчик хотят уменьшить стоимость решения, потому принимается более дешевый вариант с приемлемой скоростью работы.

Опять же начинаются ситуации когда вроде как и можно вынести что-то на СУБД, но поддержка "размазанной логики" выйдет дороже.

Егоров АлександрПроверка выполняется непосредственно в СУБД - никаких изменений в производительности всей системы опять-таки нетвот тут фундаментальная ошибка. в системах в которых скорость работы принципиальна есть правило, что любое изменение кода вызывает деградацию пока не доказано обратное. И прогонка юнитов на кластере есть как раз доказательство того, что скорость не уменьшилась.

Егоров АлександрПодправляем юнит, пересобираем систему, тестируем её опять всю целиком? Параллельно получаем "нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что модуль такой-то изменен, в отличии от базовой версии?а если мы внесли изменения в ХП это не будет ""нестандартную" версию системы у конкретного клиента, к которой начинаем где-то помнить, что ХП такой-то изменен, в отличии от базовой версии?"

2 iscrafm

Пожалуй вот это высказывание наиболее точно указывает на разницу в подходах.
carperТут кроется противоречие - заказчику очень редко нужна универсальность, универсальность нужна разработчику, чтобы увеличить продажи.
Поскольку одному нужен пылесос, а другому швабра, разработчики привязывают пылесос к швабре и удивляется почему одни жалуются на то, что швабра слишком тяжелая и занимает много места, а другие на то, что им очень мешает пылесосить деревянная палка и тряпку постоянно засасывает в пылесос.+1

iscrafmVoDA какое изменение БЛ может быть в момент внедрения?
Вы это только в слух не говорите в серьезном обществе.как скажешь

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

iscrafmт.е. Вы признаете, что находитесь в погоне за универсальностью. Страннно. Тогда смысл Ваших постов становится еще более непонятным. Говорите что это плохо, но отстаиваете. Я понимаю, типа работа такая, но....я стараюсь понять почему большие приложения чаще пишутся применяя АппСервер, а не внутри СУБД. Тот же 1С или MS Axapta в качестве примера.

Егоров АлександрЯ не смогу уговорить боссов на покупку системы, которая на каждый чих потребует "новый контракт+новая разработка+новое внедрение". У нас гибкий бизнес. Правила меняются достаточно часто, особенно скидки, и ограниченения по ним. :)Тогда вам выгоднее получить / сделать систему типа ERP имеющую свой встроенный язык- к примеру AX или 1С.

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

Егоров АлександрМассовая обработка данных - это, например, поток заявок покупателя, каждую позицию которых нужно проверить на корректность скидки? Представляете какой трафик поднимется между СП и БД, если таких заявок забивается тысячи в день, и в среднем состоят из десятков позиции, а некоторые и до сотни? ;) согласен, что оперирование массивом данных проще на СУБД.

Могу даже добавить что мат.операции над байтами (когда по массиву байт пройтись и увеличить на единицу) намного быстрее сделать на С/С++, а не java. Из-за дополнительных проверок введенных в java.

Егоров АлександрНо вроде как рынок дает основания считать, что больше всего денег зарабатывают те, кто создает всякие фреймворки (конфигураторы, конструкторы, платформы и т.д.) и базовый бизнес-функционал в качестве демонстрации возможностей. Думаю, архитектурыне вопросы очень сильно зависят от того, разработкой каких именно систем заниматься. Это, кстати, тоже может быть причиной непонимания друг-друга... :)Мы делаем любые системы Вот пару лет назад нам аутсорсили софт для формацевтических лабораторий, а в прошлом году эм... софт для голосового управления / помощи работникам складов перепиливали под нужды ... сортировочного цеха. Системы совсем не связанные друг с другом. Только принципы остаются общие, да написаны на одних и тех же фреймворках (Java) + требуют одинаковые сервера.

iscrafmстоп! а кто говорил о голой СУБД без апп-сервера? С моей стороны было бы нелогично, учитывая что моя компания выпускает 3-звенную платформу и все проекты делает на ней. :) Речь, насколько я помню, идет о реализации бизнес-логики. Центром является APP сервер. Он и распределяет, какой фрагмент выполнить средствами СУБД, а какой другим способом.тогда нам проще будет найти точки взаимодействия.

Выгода для производителя выносить логику на АппСервер:
1. дешевле нанять разработчиков на одном языке (АппСервера) чем на нескольких (АппСервер) + СУБД.
2. независимость от СУБД делает продукт более конкуренто-способным на большинстве рынков. Т.к. больше покупателей.
3. *сейчас только подумал* закрытость кода вынуждает заказчиков покупать саппорт или платить дополнительно за доводку системы.
4. бОльшее количество задач может быть решено на уровне АппСервера, а не СУБД. СУБД не годится ни для чего кроме оперирования персистными данными.

Опять же в совсем больших системах с сотнями апп-серверов переносить БЛ с Апп на СУБД... ИМХО убьет производительность.