Если у вас был администратор баз данных, который отвечал за развертывание баз данных в живой среде, что бы вы ему выбрали? Сценарий создания базы данных или резервную копию, которую он мог бы восстановить в существующей базе данных? Какие существуют преимущества/недостатки? (Мы используем MSSQL2000 и MSSQL2005)Развертывание базы данных: сценарий или резервное копирование
Хотя я согласен с первым предложением развертывания Джона использования резервной копии базы данных, я предпочитаю идею, по крайней мере, имеет сценарий, доступный для обзора, чтобы обеспечить проверки стандартов кодирования, оценки эффективности и т.д.
Если вы «Ищите« под ключ »что-то, что уже было рассмотрено, тогда резервное копирование/восстановление является идеальным вариантом для первого развертывания, тем более, если в этой базе данных есть« настроенные »данные конфигурации. Это помогает избежать длинных или сложных операторов вставки.
Его данные, выходящие за рамки первого, будут написаны сценарием. В нашей среде нам нужны заметки о выпуске, чтобы указать сервер, экземпляр и путь к сценариям. Сценарии должны быть представлены в числовом порядке, разделены на папки целевой базой данных, со вторым набором сценариев отката. Мы даже требуем, чтобы каждый скрипт имел инструкцию USE вверху, поэтому нам не нужно беспокоиться о создании новых объектов в основной базе данных! ;)
Сценарий создания БД лучше - вы всегда можете открыть блокнот и исправить его.
Я не уверен в опции резервного копирования, но с созданием db-скрипта dba может настроить базу данных по своему усмотрению (должен, разрешений и т. Д.), А затем просто создать таблицы и т. Д. С помощью скрипта.
Я предпочитаю сценарий для развертывания, они гораздо менее навязчивы. Восстановление перезапишет всю базу данных, данные и все, что, вероятно, не очень хорошо для вашей производственной среды.
Для первое развертывание; резервная копия базы данных ... это просто так быстро и просто.
Если база данных уже активна; это должна быть серия пронумерованных скриптов. Лично я подсчитываю свои сценарии и делаю только изменения в базе данных через скрипт. Это гарантирует, что все базы данных синхронизированы или могут быть синхронизированы очень легко.
Некоторые люди думают, что это своего рода анал ... но у меня никогда не будет проблемы с развертыванием производства.
Я предпочитаю сценарий, потому что вы можете поместить его в репозиторий и отслеживать его. Вы также можете легко запустить его на удаленном сервере.
Использование сценариев под управлением источника - прекрасное побочное преимущество в том, что вы создаете историю поиска каждого объекта в базе данных и читаете его по-человечески. Резервные копии представляют собой черные ящики - вы не знаете, что они собираются делать с вашим db.
Я бы пошел со сценариями - сочетанием удобочитаемости, совместимости с помощью контроля исходного кода и возможностью легко обрабатывать обновления для вашего ядра базы данных, чтобы это стало возможным в нашей организации.
Определенно используйте SQL-скрипты, поскольку они могут управляться версией. Предпочтительно сделать их маленькими и иметь какую-то партию, чтобы запускать их в известном порядке (поэтапно), так что их легко запустить в базе данных, которая уже находится в производстве.
Альтернативой SQL-скриптам является использование инфраструктуры миграции. Вы указываете изменения базы данных небольшими шагами в исходном коде.Преимущество структуры миграции заключается в том, что прогамма, которая не знает SQL, может просто внести изменения в базу данных (которая, однако, не устраняет необходимость знать некоторые основы базы данных).
Они довольно подробно о том, как вы наращиваете и сбрасываете базу данных в пошаговом шаге. Это упрощает тестирование и повторное создание ошибок в разных версиях системы или приложения базы данных.
Некоторые примеры механизмов миграции, которые я знаю, являются:
Резервное копирование предназначено для фактической резервной копии базы данных. По мере роста базы данных переносимость уменьшается. Поэтому программисту требуется только подмножество данных. По соображениям безопасности они должны обрабатывать тестовые данные вместо реальных данных. Хорошая практика заключается в том, чтобы иметь генератор тестовых данных в руке, чтобы разработчики и тестеры могли протестировать их реализацию без ущерба для данных в производстве.
При использовании резервного копирования базы данных это простое решение для первоначального развертывания, оно может быть не лучшим решением при развертывании на серверах с разными региональными настройками, чем сервер, с которого была сделана резервная копия. Мы использовали этот подход в прошлом и столкнулись с проблемами после того, как с конфликтами сортировки для наших клиентов превыше всего. Резервное копирование базы данных сохраняет свою сортировку, в то время как скрипт создаст базу данных в настройке по умолчанию для сервера (если вы не укажете ее). По этой причине мы перешли к сценариям для первоначального развертывания и последующих обновлений. – Parmenion