Здравствуйте, btn1, Вы писали:

B>Во-первых, речь вообще не про апгрэйд, а про принципиальные возможности хранимок и кода на ЯВУ внутри модели.
Принципиальные возможности одинаковые. И то и другое полно по тьюрингу.

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

B>работа хранимок/кода в реале и их ALM. Пока что преимуществ хранимок высказано не было, только намёки на теоретический бенефит от работы хранимки "как бы внутри" сервера.
Как раз в ALM и есть самая проблема. В базе можно одновременно обновлять схему и логику, причем транзакционно. Если у тебя раздельное обновление кода (в приложении) и схемы (в базе), то надо обеспечить работу старого кода с новой схемой. Даже имея трехзвенное приложение с логикой на сервере, довольно сложно синхронно обновить все экземпляры сервера.

S>>Ещё раз вчитайтесь в вопрос: как вы собираетесь свести обновление 1500 клиентов в 30 офисах и 11 часовых поясах к "секундному делу"?
B>Я отвечу на этот второстепенный вопрос, но продолжать "тему обновлений" не вижу смысла — вы ушли от главного и мусолите детали.
То есть хорошего решения для этого случая, кроме логики в базе, практически нет.

B>1. Даже если мы возьмём систему, где широко используют хранимки, в ней всё равно не избежать какой-то логики на стороне сервера приложений (рассматриваются только трёхзвенные системы как наиболее передовая архитектура). А значит "обновления хранимок" — лишь часть того, что нужно обновлять на сервере, т.е. мы по-любому не избегаем процедуры обновления сервера.
Неверно. Логику в базе можно инкасулировать настолько, что клиент многие изменения и не увидит. Хотя для случаев когда приложение монопольно работает с базой такой необходимости нет.

B>2. Если у вас 30 филиалов, очевидно, что этим занимается далеко не один человек. Распределить задачу обновления — административная хрень.
Хорошая отмазка для менеджмента, но по сути перекладывание с больной головы на здоровую.

B>3. Если для вас "остановить сервер, обновить, запустить" — проблема, то наверное есть смысл улучшить свою квалификацию? Есть тысячи систем, которые обновляют, и которые продолжают работать — весь вопрос лишь в аккуратности процесса и дотошности контроля качества обновления.
А если 10 серверов, все остановить? А если 24\7 клиенты ходят? А если не все серверы останавливать, то что станет когда база уже обновится, а не везде еще новый код работает?
Да, проблемы решаемые, но небесплатно. Причем чем больше проблема с обновлением клиентов для СУБД, тем выгоднее логика на стороне СУБД.
Тут нет универсального подхода.

B>Вопрос "обновления" — вопрос ни о чём, с тем же успехом можно обсудить подсветку T-SQL в студии — это далеко не самое интересное в вопросе "хранимки vs код".
По секрету скажу — установка и обновления это основные проблемы во всей разработке. В совокупности гораздо сложнее, чем все написание кода на ЯВУ обычно.