Как я могу запустить несколько версий моего приложения для одной и той же базы данных?

Question

Фон : у меня в рабочей среде запущено несколько версий моего приложения.В зависимости от используемой учетной записи, пользователь будет иметь доступ к другой версии программного обеспечения.

Среда : В настоящее время SQL Server 2005, неизбежно мигрирует на SQL Server 2008, ASP.Net

Проблема : Каждая версия программного обеспечения может использовать или не использовать разные версии хранимых процедур, которые взаимодействуют с данными в базе данных.В настоящее время при изменении версии любой, кто ее изменяет, создает новую копию и добавляет в конец добавочный номер версии.На данный момент у нас есть многочисленные версии некоторых сохраненных процедур и только одна версия других, и никто не уверен, какая версия приложения указывает на какую версию хранимых процедур - это беспорядок.

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

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

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

У кого-нибудь есть идеи?

Answer 1

Учитывая беспорядок, который вы описываете, если вы должны придерживаться хранимых процедур, я был бы склонен иметь только одну копию каждого сохраненного процесса, но все сохраненные процедуры принимают versionNumber в качестве окончательного параметра. Тогда у каждого хранимого процесса есть одно имя, и в контексте хранимого процесса, к которому он относится, есть любой код, зависящий от версии. Хранимые проки, которые не имеют кода, зависящего от версии, просто игнорируют этот параметр versionNumber (но все еще имеют его в своей подписи).

Одна из больших проблем, с которыми я сталкиваюсь в вашей текущей ситуации, заключается в том, что если существует 4 почти идентичных версии хранимого процесса, и кто-то исправляет ошибку в одной из них, слишком легко забыть сделать идентичное исправление в все остальные версии. Решение, которое я описал, по крайней мере уменьшит количество дублирующегося кода и уменьшит вероятность исправления ошибок только для одной версии сохраненного процесса.

Однако в этой ситуации я также чувствовал бы сильное побуждение вывести логику, относящуюся к конкретной версии приложения, из базы данных в базу кода и оставить в базе данных ту логику, которая специфична для данных, но не зависит от приложения.

Answer 2

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

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