Контроль версій за допомогою SQL Server

Я починаю новий проект і використовую SVN (з черепахою) як свою систему управління версіями. Мені було цікаво, чи можна також підтримувати базу даних SQL Server за допомогою тієї ж системи.

Я хотів би версії моїх таблиць / функцій / переглядів / procs / тригерів / тощо. але не мої дані, оскільки все одно це будуть тестові дані. Я не дуже впевнений, як це налаштувати. Я зіткнувся з декількома варіантами, але хотів би знати, чи не було я, і якщо там, можливо, посібник чи щось там, щоб допомогти мені з цим працювати.

Я бачив і чув про Red Gate, але шукаю щось безкоштовно (або, принаймні, дуже низьку вартість). Я знаю, що завжди міг щось написати сам, але не дуже намагаюся витрачати на це час.

Одне, на що я натрапив, - це пакет із відкритим кодом, що складається разом під назвою ScriptDB4Svn . Хтось користувався цим раніше? Це добре? Чи може він робити те, що мені потрібно для цього, і чи досить просто отримати налаштування?

З технічної точки зору вам навіть не потрібен інструмент, ви можете сценаріювати об'єкти безпосередньо та перевіряти їх у контролі джерел. Це трохи більше роботи без інструменту, але це, безумовно, працездатно.

BTW: Я використовував інструмент RedGate, і він досить гладкий і вартий грошей.

Здається, у вас в основному налаштування Microsoft. Ви можете ознайомитися з проектами баз даних (раніше відомими як DataDude). Вони в основному перетворюють T-SQL на першокласну мову в Visual Studio; ти можеш:

• Компілюйте проекти - це не просто створює остаточний сценарій, але забезпечує наявність імен об'єктів тощо.
• Виконайте статичний аналіз коду - наприклад, переконуючись, що ви завжди посилаєтесь на об’єкти, включаючи їх схему (наприклад, [dbo]у більшості випадків) для того приємного 30-відсоткового підвищення продуктивності.
• Створіть різні сценарії за допомогою порівняння різних версій проекту.
• Оновіть проект із бази даних або сценарію (інженер зворотного зв'язку).
• Intellisense.
• Інструментів для діаграми немає.

Вони добре уніфікують ваш код та код вашої бази даних під контролем джерела. Якщо людина вгору і сценарій об'єктів бази даних (замість того , щоб використовувати DaVinci інструменти в SSMS) , ви також кінчатися з допомогою одного IDE - що приємно.

Можна використовувати Рейки. Rails має концепцію міграції баз даних, яку ви можете застосувати або повернути назад. На мій досвід, це найкращий спосіб версії бази даних. Ви перевіряєте ці файли міграції у SVN.

У моєму поточному проекті ми не розробляємо додаток у Ruby, але ми все ще використовуємо Rails для управління базою даних. Я б не робив цього інакше.

Про це йшлося раніше у stackoverflow: /programming/2750278/sql-server-2008-create-database-script-schema-data-with-command-line

Крім того, ця зовнішня стаття містить деяку додаткову інформацію http://www.sqlteam.com/article/scripting-database-objects-using-smo-актуалізована разом із зразком коду у вигляді програми Windows.

Оскільки те, що ви хочете зробити, - це те, що я зробив сам для MS Access, я розповім вам, що я зробив, якщо це дає вам деякі ідеї: я написав модуль під назвою Ado2Xml, який перетворює схему та дані будь-якого ADO -доступна база даних до XML та назад. Однак він знає лише про таблиці та види; жодних збережених процедур, жодних тригерів, нічого. У будь-якому випадку, у вашому випадку цей модуль заміняється інструментом, який, імовірно, ви знайдете, який робить те, що ви хочете, з MS-SQL. Отже, щоразу, коли моя програма запускається, вона порівнює часову позначку бази даних з часовою міткою збереженого файлу xml; якщо файл XML більш пізній, він знищує базу даних і викликає Ado2Xml, щоб відновити її з файлу xml. Коли моя програма закінчується, вона робить зворотне: вона викликає Ado2Xml для експорту бази даних у файл xml. Насправді, Об'єкти ADO, які витягують схему бази даних, чомусь жахливо повільні, через що процес експортування потребує певного часу. Отже, щоб уникнути необхідності щоразу чекати, коли моя програма закінчиться, і візуальна студія переключиться з макета налагодження на макет редагування, безпосередньо перед тим, як вона завершить роботу, моя програма запустить зовнішній додаток для здійснення експорту, щоб він міг припинити роботу негайно.

Так, я використовував аналогічний інструмент (розроблений в приміщенні) для попереднього проекту. Сценаріює всі таблиці, представлення, проростки, тригери тощо в окремі файли .sql. Тоді у нас був сценарій, який виконувався щовечора, щоб "перевірити", що все в нашій базі даних "розробки" відбилося на контролі джерел.

Таким чином, нормальний робочий процес полягає в тому, що ви можете змінити свій код, змінити відповідні таблиці та проростки в базі даних розробок, якщо це потрібно, тоді ви запустите інструмент, який ми мали, щоб оновити всі сценарії .sql файлів. Тоді ви одразу все перевірите.

Проблема полягала в тому, що якщо ви забули запустити інструмент, код "запрацював" (і тести одиниць пройдуть), оскільки база даних була "правильною", але нові відростки / таблиці не будуть контролювати джерело.

Тому щовечора у нас є сценарій, який здійснив перевірку вихідного коду, а потім запустив інструмент для оновлення всіх сценаріїв. Якщо була якась різниця, це означає, що хтось забув перевірити їх зміни та було створено сповіщення електронною поштою. Це був лише спосіб переконатися, що ми не забули постійно оновлювати контроль джерела.

Це було трохи прикро, тому що важко було працювати над змінами, які тривали кілька днів, але це було краще, ніж нічого не мати ...