бесплатная утилита для сценария объектов БД в MS SQL

Question

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

инструмент, который мне нужен, должен создать отдельный файл для каждого объекта в базе данных, желательно в виде папок, например

хранимые процедуры функции Просмотры Таблицы

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

Интересно, есть ли уже инструмент, который может обрабатывать такие вещи ...

-

просто чтобы прояснить несколько вещей ...

Я уже использую sql delta для обработки сценариев обновления ...

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

Я разрабатываю хороший vb-скрипт с объектами распределенного управления SQL (SQL-DMO), я расскажу, как он работает ...

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

Answer 1

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

Вот партия, которую я использую. svnclient - это инструмент из codeplex svncompletesync.codeplex.com , чтобы проверять все файлы из папки в subversion .:

svn checkout "http://svn/myproject" D:\Projekte\db_svn\myproject

ScriptDB "D:\temp\scriptdb" myserver mydb mylogin mypwd

del "D:\Projekte\db_svn\myproject\Schema Objects\\*.sql" /q /s

xcopy "D:\temp\scriptdb\myserver\mydb\Schema Objects\\*.sql" "D:\Projekte\db_svn\myproject\Schema Objects" /e /y /i

svnclient "D:\Projekte\db_svn\myproject" -m "commit durch svncompletesync"

Answer 2

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

Если у вас уже есть метаданные и данные в базе данных, я не вижу, что помешает вам с помощью SQL Management Studio (или SQL Enterprise Manager) создавать сценарии из объектов базы данных: см. Как: создать сценарий (SQL Server Management Studio) . Это должно работать для SQL Server 2000, 2005 и т. Д. Имейте в виду, что вы можете настроить параметры генерации скриптов, например, вместо одного огромного сценария вы можете использовать отдельные сценарии для каждого объекта. Возможно, вам придется написать несколько скриптов для заполнения таблиц данными (я не уверен, что мастер поддерживает извлечение данных).

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

Answer 3

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

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

Answer 4

Вы можете попробовать Wizardby , что не совсем то, что вы просите, но все же может помочь вам в управлении изменениями базы данных. Он может перепроектировать вашу схему базы данных (ну, подмножество ее), а затем записать так называемые «миграции» в специальный независимый от платформы DSL:

version 20090331140131:
    oxite_FileResource:
        FileResourceID type => PK, primary-key => true
        SiteID type => Guid, nullable => false
        FileResourceName type => LongName
        CreatorUserID references => oxite_User
        Data type => Binary
        ContentType type => AnsiString, length => 25, nullable => false
        Path type => String, length => 1000, nullable => false
        State type => Byte, nullable => false
        CreatedDate type => DateTime, nullable => false
        ModifiedDate type => DateTime, nullable => false 

    oxite_UserFileResourceRelationship:
        UserID references => oxite_User
        FileResourceID references => oxite_FileResource:
            add index unique => true

        index "" columns => [UserID, FileResourceID], unique => true, clustered => true