Пошаговые инструкции по обновлению базы данных (SQL Server)?

Question

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

Моя проблема проста. Я работаю над проектом, который будет использовать SQL Server. Там нет проблем, так как я достаточно эксперта, чтобы справиться с этим Но этот проект будет обновлен позже, и мне нужно указать протокол, которому должен следовать механизм обновления. По сути, этот протокол необходимо соблюдать при создании сценариев обновления ...

Прямо сейчас у меня есть следующие простые шаги:

1. Добавить новые столбцы в таблицы.
2. Добавить ограничения для новых столбцов.
3. Добавить новые таблицы.
4. Отбросьте ограничения там, где это необходимо.
5. Удалите столбцы, которые необходимо удалить.
6. Удалите таблицы, которые необходимо удалить.

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

Кроме того, всегда ли можно выполнить полное обновление в рамках одной транзакции базы данных (с SQL Server) или есть точки прерывания, которые необходимо включить в протокол, где одна транзакция должна завершиться, а другая начинается?

---

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

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

---

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

Во время разработки все разработчики используют свой собственный экземпляр базы данных, который они могут полностью контролировать. Поскольку мы не те, кто использует приложение, мы стремимся разрабатывать для редакции Express, а не более дорогой. Если честно, мы не разрабатываем наше приложение для поддержки большого количества пользователей, но мы сообщим нашим пользователям, что, поскольку оно использует SQL Server, они могут установить систему на более крупную платформу SQL Server в соответствии со своими потребностями. Для этого им понадобится собственный DBA. У нас есть более мощный SQL Server, который мы также используем для нашего собственного веб-интерфейса, но этот сервер находится на специальном сервере данных, где он поддерживается для нас, а не для нас.

В проекте ранее использовался MS Access для хранения данных, и он предназначался для однопользовательской разработки, но, как оказалось, многие пользователи по-прежнему решили совместно использовать свои базы данных, и это показало, что сама модель данных достаточно надежна для пользовательские среды. Поэтому мы перешли на SQL Server для поддержки небольших офисов с 3 или более пользователями и крупной организацией, в которой одновременно будет 500 или более пользователей.

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

Answer 1

Проверьте Red-Gate SQL Compare (сравнение структур), SQL Data Compare (сравнение данных) и SQL Packager (для упаковки скриптов обновлений) в проект C # или исполняемый файл .NET).

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

Настоятельно рекомендуется!

Answer 2

На мой взгляд, это абсолютный медведь, делающий это вручную. Для Microsoft SQL Server я бы порекомендовал использовать редактирование базы данных Team System, поскольку оно включает в себя полные возможности управления исходным кодом для вашей базы данных и может автоматически создавать сценарии для обновления / понижения версии.

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

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

Опять же, несмотря на то, что возможно создать протокол вручную, я бы все-таки воспользовался одним из специально созданных инструментов, и Team System и SQL Compare смогут выводить сценарии, которые можно включить как часть. пакета установки / обновления.

Answer 3

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

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

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

Answer 4

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

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

Надеюсь, это поможет.