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

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

1) Есть примерно десяток приложений которые работают на нескольких сотнях компьютеров в локальной сетке и используют одну базу данных.

2) В базе денных имеется набор stored procedure которые обеспечивают некоторую функциональность приложений

Система работает, всё в порядке...

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

Здесь возможно несколько вариантов:

1. Новое приложение не требует изменений SP (здесь всё просто, не рассматриваем)

2. Новое приложение вообще не требуется, надо изменить только SP
Тут возникает масса проблем, дело в том что на каком-то этапе после тренировок на кошках (в тестовой среде и тестовых базах данных), надо протестировать работоспособность в реальных условиях, причём делать это надо не меняя все приложения во всей системе, а например поменять только 1-2 приложения из нескольких сотен и посмотреть... Вот варианты которые я вижу с граблями:

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

- Можно написать новую SP (или версию SP) и изменить приложение чтобы новый exe использовал новую версию SP. Но тогда возникает 2 неудобства: во-первых надо менять exe фaйл на практически такой же, причём в перспективе на многих машинах, что процесс достаточно трудоёмкий, во-вторых появляется 2 SP которые используются одновременно, с тем что одно приложение использует сотни SP, а самих приложений тоже не мало, то с течением времени появляется в базе данных по десятку вариантов SP для каждой хранимки, часть из которых используется, а часть нет... Через какое-то время становится достаточно сложно предсказать используется какая-то SP каким-либо приложением или нет... Т.е. конечно можно вести подробную документацию на каждую версию каждого приложения, но всё равно - это ручная работа, следовательно возникают варианты когда кто-то что-то забыл где-то записать, в итоге имеем либо мусор, либо того хуже стёрта нужная хранимка.

- Можно сделать data dictionary где хранить имя компа+имя програмы+внутренее название SP и ассоциированное имя (версия) реальной SP. Тогда менежмент версий станет очень лёгкий, сразу видно кто что использует, при смене версии SP не надо менять ничего локально, достаточно работать с базой данных, откат в случае ошибок очень лёгкий... но(!) - это дополнительный запрос на каждый вызов хранимки, при потоке запросов на сервер до сотни в секунду, это означает практически удвоение количества запросов! Кроме того нужны существенные изменения кода в продуктах для поддержки этой системы, следовательно чтобы идти по этому вроде бы наиболее привлекательному варианту мне нужны веские основания...

- Можно имена используемых SP хранить в каком-то ini файле локально... Тогда вроде бы напряга для сервера не будет, но любой update потребует обходить все рабочие станции и чего-то там менять...

3. Если надо поменять и приложение и SP. В принципе почти вариант 2, но прельщает просто в коде указать версию используемой SP, как наиболее простом и быстром варианте решения, однако остаются проблемы перечисленные выше.

Хотелось бы узнать, есть ли у кого реальный опыт разруливания таких ситуаций?

Цитата

- Можно имена используемых SP хранить в каком-то ini файле локально... Тогда вроде бы напряга для сервера не будет, но любой update потребует обходить все рабочие станции и чего-то там менять...

, на мой взгляд этот вариант самый оптимальный (если под это заточены написанные клиенты);

Только, на мой взгляд лучше использовать не ini, а dll со строковыми ресурсами (чтобы пользователи ничего не наменяли своими руками);

т.о. обновление может происходить по схеме:

1) генерация скрипта на сервере (рабочем) - серверное обновление;
2) раскладывание по сети (клиенты указываются) скриптом в %windows% - и никуда ходить не нужно;