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

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, как наиболее простом и быстром варианте решения, однако остаются проблемы перечисленные выше.

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

Вариант (для Oracle)
1. Пусть имеем рабочую схему (user) WORK
2. Создаем тестовую схему TEST, в нее помещаем синонимы на ВСЕ объекты схемы WORK.
3. Если нужно протестировать SP, помещаем ее новую версию в TEST, удалив синоним.
4. По окончании тестирования переносим SP в WORK и восстанавливаем синоним.
"Подопытные" на период тестирования делают connect TEST, по окончании, как и остальные, - connect WORK

Цитата(igon @ 20.7.2005, 03:38)

Вариант (для Oracle) 1. Пусть имеем рабочую схему (user) WORK 2. Создаем тестовую схему TEST, в нее помещаем синонимы на ВСЕ объекты схемы WORK. 3. Если нужно протестировать SP, помещаем ее новую версию в TEST, удалив синоним. 4. По окончании тестирования переносим SP в WORK и восстанавливаем синоним. "Подопытные" на период тестирования делают connect TEST, по окончании, как и остальные, - connect WORK

Можно без синонимов, просто повесив триггер на CONNECT, переключать умолчальную схему. Пользователей различать или по имени, или по машине, или по имени приложения.

Цитата

Можно без синонимов

Пусть в WORK имеем SP mySP, использующую myTable (фактически WORK.myTable).
Чтобы тестовая версия mySP работала в TEST в условиях, максимально приближеных к "боевым", нужно
1) либо вместе с mySP скопировать в TEST таблицу myTable и потом следить за TEST.myTable==WORK.myTable
2) либо в TEST Create Synonym myTable for WORK.myTable
Второй вариант, ИМХО, предпочтительней

Переключение на нужную схему в момент CONNECT`а, безусловно, хорошее дополнение: "подопытным" не придется менять свои настройки, а все управление TEST<-->WORK можно будет сосредоточить в БД

Спасибо, метод нравится, хотя и не без изъянов. ПОсмотрим какие ещё будут идеи