Как поставить большую существующую базу данных (схему) под контроль исходного кода?

Question

Мой DBA только что потерял некоторые разработки, которые он делал в нашей базе данных разработки. Бедный парень. Поэтому, естественно, наш менеджер спросил его на нашем совещании о статусе, как это может произойти и как мы могли бы избежать этого в будущем. «Контроль источников может облегчить проблему», - предложил я ... Ответ DBA; «Нет, мы просто делаем резервную копию сервера чаще». Теперь я хотел бы помочь моему администратору баз данных понять, что такое контроль исходного кода и как он сочетается со схемой базы данных и разработкой этой схемы.

Ранее я пытался объяснить ему, что нет ничего особенного в исходном коде таблиц и хранимых процедур, и он должен быть в системе контроля версий (в данном случае TFS). Но он просто не кусал. Теперь, пока эта ошибка отсутствует в недавней памяти, я хотел бы сделать еще один удар.

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

Несколько фактов об окружающей среде:

• Контроль версий на сервере TFS 2008.
• База данных - это сервер MS SQL 2008 с> 300 таблицами и> 300 другими объектами (sprocs, триггеры, функции и т. Д.).

Пояснение: В прошлом мы использовали DB Ghost и другие решения по управлению изменениями в других проектах с другими администраторами баз данных. У нас даже есть лицензия на издание VS DB! Проблема состоит в том, чтобы заставить администратора даже подумать об этом способе разработки для базы данных. Он действительно старая школа (т.е. переносит изменения вручную из среды в среду), и, к сожалению, он единственный, кто знает что-либо об этой конкретной БД.

Answer 1

См. , как управлять версиями баз данных SQL Server и Вы управляете источниками своих баз данных , среди многих других. Или используйте search page . В принципе, ваш подход кажется правильным. Удачи в убеждении DBA ...

Answer 2

Если вы используете Visual Studio Team System, я рекомендую сделать укол в их Database Edition (я думаю, что в настоящее время он поставляется с Developer Edition, если вы являетесь подписчиком MSDN). Это позволит вам сделать так, чтобы все ваши схемы, хранимые процессы, представления, триггеры и т. Д. Были записаны в сценарий, а также контролировали их источники. Это также должно сделать dba более комфортным, так как он будет работать с версией инструмента «База данных», а не с версией «Разработчик» (именование может иметь большое значение для людей). Внося изменения из Visual Studio, вы можете управлять изменениями сценариев во время работы и контролировать их исходные коды.

Answer 3

Как менеджер по продукту для SQL Compare, я говорил со многими «традиционными» администраторами баз данных, которым не нравятся сторонние инструменты, в основном из-за того, что у них есть система, которая работает для них, и иногда изменение может быть затруднено. Во многих ситуациях я убежден, что они воспользуются нашими инструментами, если только они дадут им шанс. Разочарование.

Одна вещь, которую вы могли бы попробовать - это новый инструмент Red Gate, контроль исходного кода SQL. Это предназначено для встраивания контроля исходных кодов в SSMS, иными словами, не требуется, чтобы администраторы баз данных покидали комфортную зону своей среды управления. Плохая новость заключается в том, что инструмент еще не выпущен. Хорошей новостью является то, что у нас есть программа раннего доступа. Пожалуйста, перейдите по следующей ссылке, чтобы узнать больше об инструменте:

http://www.red -gate.com / Продукты / SQL_Source_Control / index.htm

Answer 4

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

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

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

Answer 5

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

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

Для меня это скорее процедурная ошибка.

Почему изменение не было сделано из сценария? Забудьте, где находится сценарий, но почему нет воспроизводимого и повторно запускаемого сценария? Возможно, связано с номером отслеживания изменений? Если база данных будет сброшена (загружена из prod), то как изменение будет применено повторно для подготовки к производству. И другие вопросы.

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

Answer 6

Если ваша компания имеет лицензию MSDN, они могут использовать редакцию базы данных Visual Studio. Здесь есть видеоурок здесь .

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

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

Answer 7

Мой ответ на эту же проблему состоял в том, чтобы экспортировать все объекты БД в текстовую форму (более 136 000 из них), а затем создать проекты SourceSafe для их хранения. Все новые или измененные объекты в БД теперь переходят в структуру SourceSafe, а неизмененные остаются одни.

Answer 8

Не ясно из вашего вопроса, хотите ли вы защитить данные в БД или схемы в БД. Если последнее, то вы могли бы идентифицировать все важные схемы и запустить задание cron, которое извлекает определения схемы из базы данных и автоматически вставляет их в систему управления версиями (возможно, даже через триггеры на схемах ??).

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

(и мне кажется, что VSS интегрирован в SQL Management Studio: - (()

Answer 9

Один из способов управления исходной базой данных - это отдельно хранить данные в базе данных и о ней

1. Вы можете иметь все таблицы, процедуры и функциональные сценарии в виде файлов SQL и добавлять их в систему контроля версий.

2. Экспорт данных базы данных в виде операторов вставки в файлы SQL, каждый из которых имеет фиксированный размер. Это громоздкий процесс, так как он требует много файлов, которые нужно отслеживать и контролировать.

3. Я не уверен, что VSS / SVN способны считывать и сохранять историю изменений в файлах дампа, созданных параметрами резервного копирования базы данных.

Answer 10

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

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