Рекомендации по изменению схемы SQL Server 2008

Если обновления изменяют такие вещи, как имена столбцов, сохраненные параметры процесса и т. д., всегда переводите приложения в автономный режим перед выполнением обновления схемы.

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

Если кто-то использует приложение во время обработки обновления схемы, вы вполне можете оказаться в ситуации, когда целостность данных нарушена.

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

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

Кроме того, мы используем такие инструменты, как SQL Compare от Redgate, для сценариев обновлений нашей базы данных. Это практикуется на промежуточном сервере, который был обновлен из производственных данных до фактической отправки, чтобы гарантировать отсутствие неожиданностей и возможность сделать это очень быстро.

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

Я не рассматривал маршрут .cs/ado.net для внесения изменений в схему. Что мы делаем, так это создаем «дельта» файлы .SQL — SQL для внесения изменений. Они выполняются по схеме известной версии для внесения изменений, а запуск .SQL является частью развертывания.

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

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

Сохраняя изменения схемы в SQL, они больше похожи на «главную» схему SQL, которую они модифицируют, и поэтому их легче отслеживать. Меньше отлаживать тоже!

Они также управляются в TFS вместе с остальным кодом.

Идеальная ситуация, но не всегда достижимая: вы вносите изменения в схему, совместимые со «старой» версией вашего сайта. Затем вы выпускаете V‹new› на свои веб-серверы. Как только все ваши веб-серверы будут переведены в состояние V‹new›, вы можете выполнить любую очистку (заполнение отсутствующих значений и т. д.), а затем внести соответствующие изменения, допускающие значение null.