Поддержка бета и производственной версии в одной базе данных

Question

У нас есть продукт с SQL Server в качестве внутренней базы данных. Теперь у нас есть постановка проблемы, что всякий раз, когда развертывается новая версия, она должна использоваться несколькими пользователями, а другие будут продолжать использовать более старые версии.

Со стороны приложения мы можем поддерживать два экземпляра, но базу данных мы не можем сделать просто так, потому что транзакция и основные данные должны быть единичными. Изоляция кода в базе данных невозможна.

Любые входы?

Примечание. Приложение, имеющее конфигурации, которые были сохранены в базе данных.

Answer 1

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

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

   CREATE PROCEDURE [DoSearch]
       @NAME VARCHAR(50),
       @BIRTHDAY DATE = NULL -- Defaults value means it's optional
   AS ...
   

ПРИМЕЧАНИЕ. Когда старый код вызывает эту хранимую процедуру, @BIRTHDAY не передается. Но, поскольку он имеет значение по умолчанию, SQL счастлив.

2. Для больших изменений (например, изменение набора результатов) мы создаем добавление номера версии хранимой процедуры и вызываем его из обновленного приложения:

   CREATE PROCEDURE [DoSearch_v2]
       @NAME VARCHAR(50)
   AS
       SELECT FIELD1, 
              FIELD2, -- different data type than v1 of stored procedure
              FIELD3, -- a field not returned by v1 of stored procedure
   

3. Для серьезных изменений ...

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

    CREATE DATABASE [App_Data] -- Only has tables
    CREATE DATABASE [App_SPROCS_V1] -- References [App_Data]
    CREATE DATABASE [App_SPROCS_V2] -- References [App_Data]

Веб-сайт для Клиента-А использует «старое» приложение и поэтому указывает на [App_SPROCS_V1].

Веб-сайт для Customer-B использует «новое» приложение и поэтому указывает на [App_SPROCS_V2].

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

Примером того, когда мы это сделали, является обновление нашего веб-сайта с .NET 4.x до .NET Core. Мы воспользовались возможностью, чтобы сделать тонну уборки дома и повторной реализации функций. Мы не хотели «сгибать» текущие хранимые процедуры, поэтому создали все новые в [APP_SPROCS_V2].

Answer 2

Вы хотите знать, как две версии вашей системы совместно используют базу данных - старый код и новый код?Если нет никаких изменений схемы, это не должно быть проблемой.Если изменения схемы являются аддитивными (новые представления, новые таблицы, новые столбцы с соответствующими значениями по умолчанию), в общем, это тоже хорошо.

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

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

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