Развертывание базы данных: сценарий или резервное копирование - PullRequest
6 голосов
/ 29 января 2009

Если бы у вас был администратор БД, который отвечал за развертывание баз данных в реальной среде, что бы вы ему дали? Сценарий создания базы данных или резервная копия, которую он может восстановить в существующую базу данных? Какие есть преимущества / недостатки? (Мы используем MSSQL2000 и MSSQL2005)

Ответы [ 9 ]

6 голосов
/ 29 января 2009

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

5 голосов
/ 29 января 2009

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

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

Это данные, которые выходят за пределы первого, будут написаны по сценарию. В нашей среде нам требуются примечания к выпуску для указания сервера, экземпляра и пути к сценариям. Сценарии должны быть представлены в числовом порядке, разделены на папки целевой базой данных со вторым набором сценариев отката. Мы даже требуем, чтобы каждый скрипт имел оператор USE вверху, поэтому нам не нужно беспокоиться о создании новых объектов в главной базе данных! ;)

3 голосов
/ 29 января 2009

Для первого развертывания ; резервное копирование базы данных ... это просто так быстро и просто.

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

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

1 голос
/ 30 января 2009

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

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

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

Вот некоторые известные мне примеры миграционных структур:

  • Migratordotnet для .NET, которые запускаются в сценариях сборки, таких как msbuild.
  • Ruby on Rails использует миграцию, которая запускается через Rake.

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

1 голос
/ 29 января 2009

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

1 голос
/ 29 января 2009

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

1 голос
/ 29 января 2009

Я не уверен насчет опции резервного копирования, но с помощью сценария создания базы данных dba может настроить базу данных так, как он хочет (должен, разрешения и т. Д.), А затем просто создать таблицы и т. Д. С помощью сценария.

0 голосов
/ 30 января 2009

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

0 голосов
/ 29 января 2009

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

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