[Database] Используете ли вы источник управления для своих элементов базы данных?


Answers

Сами базы данных? нет

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

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

Question

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

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

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

Есть ли какие-либо рекомендации для этого? Каковы некоторые стратегии, которые сработали для вас?




Мы используем версию и источник для управления всеми нашими базами данных:

  • DDL (создавать и изменять)
  • DML (справочные данные, коды и т. Д.)
  • Изменение модели данных (с использованием ERwin или ER / Studio)
  • Изменения конфигурации базы данных (разрешения, объекты безопасности, общие изменения конфигурации)

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




Проверьте LiquiBase для управления изменениями базы данных с помощью источника управления.




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

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

Удачи вам, чем скорее вы попробуете, тем скорее у вас будут проблемы.




Самая успешная схема, которую я когда-либо использовал в проекте, объединила резервные копии и дифференциальные файлы SQL. В принципе, мы бы взяли резервную копию нашего db после каждой версии и сделали дамп SQL, чтобы мы могли создать пустую схему с нуля, если бы нам это было нужно. Тогда в любое время, когда вам нужно было внести изменения в БД, вы добавили бы скрипт alter в каталог sql под управлением версии. Мы всегда будем указывать порядковый номер или дату имени файла, поэтому первое изменение будет выглядеть как 01_add_created_on_column.sql, а следующий скрипт будет 02_added_customers_index. Наша машина CI проверяет их и запускает их последовательно на новой копии db, которая была восстановлена ​​из резервной копии.

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




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




ДА, я думаю, что важно обновить вашу базу данных. Не данные, а схема наверняка.

В Ruby On Rails это обрабатывается каркасом с «миграциями». Каждый раз, когда вы изменяете db, вы создаете скрипт, который применяет изменения и проверяет его на исходный элемент управления.

Мой магазин так понравился этой идее, что мы добавили функциональность в нашу сборку на основе Java, используя сценарии оболочки и Ant. Мы интегрировали этот процесс в нашу процедуру развертывания. Было бы довольно легко написать сценарии, чтобы сделать то же самое в других средах, которые не поддерживают выпуск версии DB из коробки.




Если ваша база данных - это SQL Server, у нас может быть только решение, которое вы ищете. SQL Source Control 1.0 теперь выпущен.

http://www.red-gate.com/products/SQL_Source_Control/index.htm

Это интегрируется в SSMS и обеспечивает клей между объектами базы данных и вашим VCS. «Сценарий» выполняется прозрачно (он использует механизм сравнения SQL под капотом), что должно сделать его настолько простым, что разработчики не будут обескуражены от принятия процесса.

Альтернативным решением Visual Studio является ReadyRoll , который реализуется как подтип проекта базы данных SSDT. Это требует подхода, ориентированного на миграцию, который больше подходит для требований к автоматизации команд DevOps.




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

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

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




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

Я могу предложить использовать надстройку SSMS под названием ApexSQL Source Control . Это позволяет разработчикам легко сопоставлять объекты базы данных с исходной системой управления с помощью мастера непосредственно из SSMS. Надстройка включает поддержку TFS, Git, Subversion и других SC-систем. Он также включает в себя поддержку источника управления статическими данными.

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

Вы можете прочитать эту статью для получения дополнительной информации: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/




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




Да, мы делаем это, сохраняя наш SQL как часть нашей сборки - мы сохраняем DROP.sql, CREATE.sql, USERS.sql, VALUES.sql и их версию, поэтому мы можем вернуться к любой помеченной версии.

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

Кроме того, SQL затем помечен вместе с исходным кодом, который идет с ним.




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

Инструментом, который я использовал в прошлом, который помог с этим, является SQL Delta. Он покажет вам различия между двумя базами данных (SQL Server / Oracle, я считаю) и создаст все сценарии изменений, необходимые для переноса A-> B. Еще одна приятная вещь - показать все различия между содержимым базы данных между производственной (или тестовой) БД и вашей БД разработки. Поскольку все больше и больше приложений хранят конфигурацию и состояние, которое имеет решающее значение для их выполнения в таблицах базы данных, может быть настоящей болью иметь сценарии изменений, которые удаляют, добавляют и изменяют правильные строки. SQL Delta показывает строки в базе данных так же, как они будут выглядеть в инструменте Diff - изменена, добавлена, удалена.

Отличный инструмент. Вот ссылка: http://www.sqldelta.com/







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