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

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

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

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

Я делаю это, сохраняя сценарии создания / обновления и сценарий, который генерирует образцы данных.

Должен читать Получите вашу базу данных под контролем версий. Проверьте серию сообщений К. Скотта Аллена.

When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.

Да ... наши базы данных созданы в ERwin, и DDL для каждой версии генерируются автоматически. Файлы ERwin хранятся в нашей системе управления исходным кодом (на самом деле, наши инженерные документы тоже).

Мне очень нравятся миграции Rails ActiveRecord. Он преобразует DML в сценарий ruby, который затем можно легко версировать в исходном репозитории.

Однако, приложив немного усилий, вы можете сделать то же самое. Любые изменения DDL (ALTER TABLE и т. д.) Могут быть сохранены в текстовых файлах. Сохраните систему нумерации (или отметку даты) для имен файлов и применяйте их последовательно.

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

У нас есть еженедельный дамп sql в репозиторий Subversion. Это полностью автоматизировано, но это ДЕЙСТВИТЕЛЬНО сложная задача.

Вы захотите ограничить количество ревизий, потому что через некоторое время это действительно съедает дисковое пространство!

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

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

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

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

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

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

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

Лучшая практика, которую я видел, - это создание сценария сборки для удаления и восстановления вашей базы данных на промежуточном сервере. Каждой итерации была предоставлена ​​папка для изменений базы данных, все изменения были написаны с помощью сценария «Drop ... Create». Таким образом, вы можете в любой момент вернуться к более ранней версии, указав сборку в папке, для которой вы хотите выполнить версию.

Я считаю, что это было сделано с помощью NaNt / CruiseControl.

Мы используем репликацию и кластеризацию для управления нашими базами данных, а также для резервного копирования. Мы используем Серена для управления нашими сценариями SQL и реализациями конфигурации. Перед изменением конфигурации мы выполняем резервное копирование в рамках процесса управления изменениями. Эта резервная копия удовлетворяет нашим требованиям к откату.

Думаю, все зависит от масштаба. Вы говорите о корпоративных приложениях, которым необходимо внешнее резервное копирование и аварийное восстановление? Небольшая рабочая группа, использующая бухгалтерское приложение? Или где-то посередине?

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

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

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

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

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

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

Наши скрипты Create / Alter находятся в системе контроля версий. Что касается самой базы данных, когда у вас есть сотни таблиц и много обрабатываемых данных каждую минуту, версия всей базы данных станет убийцей центрального процессора и жесткого диска. Вот почему резервное копирование по-прежнему, на мой взгляд, лучший способ контролировать ваши данные.

Мы настаиваем на сценариях изменений и сценариях определения основных данных. Они регистрируются в CVS вместе с любым другим исходным кодом. PL / SQL (где находился магазин Oracle) также контролируется исходным кодом в CVS. Скрипты изменений можно повторять и передавать всем в команде. По сути, только потому, что это база данных, нет оправдания, чтобы не закодировать ее и не использовать систему управления версиями для отслеживания изменений.

Никогда не следует просто входить в систему и начинать вводить команды «ALTER TABLE» для изменения производственной базы данных. В моем проекте есть база данных на каждом сайте клиента, поэтому каждое изменение в базе данных производится в двух местах: в файле дампа, который используется для создания новой базы данных на сайте нового клиента, и в файле обновления, который запускается. при каждом обновлении, которое сравнивает текущий номер версии базы данных с наибольшим номером в файле и обновляет вашу базу данных на месте. Так, например, последняя пара обновлений:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

Я уверен, что есть способ лучше, но пока он у меня работает.

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

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

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

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

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

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

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

Я использовал инструмент dbdeploy от ThoughtWorks по адресу http://dbdeploy.com/. Он поощряет использование сценариев миграции. В каждом выпуске мы объединяли сценарии изменений в один файл, чтобы облегчить понимание и позволить администраторам баз данных «благословить» изменения.

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

Я управляю версиями скрипта создания и использую в нем тег версии svn. Затем, когда я получаю версию, которая будет использоваться, я создаю сценарий в каталоге dbpatches / с именем версии, до которой нужно выполнить обновление. Задача этого сценария - изменить текущую базу данных без уничтожения данных. Например, dbpatches / может иметь файлы с именами 201, 220 и 240. Если база данных в настоящее время находится на уровне 201, примените исправление 220, а затем исправление 240.

DROP TABLE IF EXISTS `meta`;
CREATE TABLE `meta` (
  `property` varchar(255),
  `value` varchar(255),
  PRIMARY KEY (`property`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `meta` VALUES ('version', '$Rev: 240 $');

Не забудьте протестировать свой код, прежде чем считать исправление хорошим. Пусть покупатель будет бдителен!

Мы поддерживаем сценарии DDL (а иногда и DML), созданные нашим ER Tool (PowerAMC).

У нас есть набор сценариев оболочки, которые переименовывают сценарии, начиная с номера в основной ветви. Каждый сценарий фиксируется и помечается номером bugzilla.

Затем эти сценарии при необходимости объединяются в ветвях выпуска вместе с кодом приложения.

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

Я использую сценарии SQL CREATE, экспортированные из MySQL Workbech, а затем, используя их функцию «Экспорт SQL ALTER», я получаю серию сценариев создания (конечно, пронумерованных) и сценариев изменения, которые могут применять изменения между ними.

3.- Export SQL ALTER script Normally you would have to write the ALTER TABLE statements by hand now, reflecting your changes you made to the model. But you can be smart and let Workbench do the hard work for you. Simply select File -> Export -> Forward Engineer SQL ALTER Script… from the main menu.

This will prompt you to specify the SQL CREATE file the current model should be compared to.

Select the SQL CREATE script from step 1. The tool will then generate the ALTER TABLE script for you and you can execute this script against your database to bring it up to date.

You can do this using the MySQL Query Browser or the mysql client.Voila! Your model and database have now been synchronized!

Источник: MySQL Workbench Community Edition: Руководство по синхронизации схемы

Все эти скрипты, конечно же, находятся под контролем версий.

Моя команда редактирует нашу схему базы данных как классы C# с остальной частью нашего кода. У нас есть собственная программа на C# (<500 строк кода), которая отражает классы и создает команды SQL для создания, удаления и обновления базы данных. После создания базы данных мы запускаем sqlmetal для создания сопоставления linq, которое затем компилируется в другом проекте, который используется для генерации тестовых данных. Все работает очень хорошо, потому что доступ к данным проверяется во время компиляции. Нам это нравится, потому что схема хранится в файле .cs, который легко отслеживать, сравнивая в trac / svn.

Ознакомьтесь с LiquiBase для управления изменениями базы данных с использованием системы контроля версий.

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

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

Отличный инструмент. Ссылка здесь: http://www.sqldelta.com/

Да всегда. При необходимости у вас должна быть возможность воссоздать структуру производственной базы данных с полезным набором образцов данных. Если вы этого не сделаете, со временем о незначительных изменениях, направленных на то, чтобы все работало, забыли, и в один прекрасный день вас сильно укусили. Это страховка, которая, возможно, вам не нужна, но в тот день, когда вы ее сделаете, она стоит своих денег в 10 раз!

Программное обеспечение RedGate предлагает отличные инструменты, которые помогут вам версии вашей базы данных. Убедитесь, что ваши разработчики создают свои собственные изолированные локальные базы данных для работы разработчиков, а не полагаются на «сервер разработки», который может в какой-то момент отключиться, а может и не отключиться.

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

RedGate также делает снимки данных, хотя я лично с ними не работал, они столь же надежны.

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

Я использовал RedGate SQL Compare Pro для синхронизации схемы с папкой скриптов, а затем передаю все свои обновления в систему контроля версий. Отлично работает.

У вашей проектной группы может быть администратор баз данных, которому каждый разработчик будет направлять свои sql-операторы create alter, delete, insert / update (для основных данных). Администраторы баз данных будут выполнять эти запросы и после успешного выполнения требуемого обновления добавят эти операторы в текстовый файл или электронную таблицу. Каждое добавление можно пометить как точку сохранения. Если вы вернетесь к определенной точке сохранения, просто отбросьте все и запустите запросы до отмеченной точки сохранения. Этот подход - всего лишь мысль ... небольшая доработка здесь подойдет для вашей среды разработки.

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

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

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

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

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

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

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

У нас был бы файл с именем currency.sql, находящийся под подрывной обработкой. В качестве ручного шага в процессе сборки мы сравниваем предыдущий файл currency.sql с последним и пишем сценарий обновления.

Новые проекты баз данных в Visual Studio обеспечивают управление версиями и сценарии изменения.

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

Схема db «измельчается» для создания множества маленьких файлов .sql, по одному на команду DDL, описывающую базу данных.

+ Том

Доп. Информация 30.11.2008

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

Поскольку схема «измельчена» в файлы sql, система управления версиями работает нормально.

Одна проблема заключается в том, что вам нужно иметь другое мышление, когда вы используете проект db. Инструмент имеет «проект базы данных» в VS, который представляет собой просто sql, плюс автоматически сгенерированную локальную базу данных, которая имеет схему и некоторые другие данные администратора, но не содержит данных вашего приложения, а также вашу локальную базу данных разработчика, которую вы используете для работа разработчика данных приложений. Вы редко знаете о автоматически сгенерированном db, но вы должны знать его там, чтобы вы могли оставить его в покое :). Этот специальный db легко узнаваем, потому что в его имени есть Guid,

Проект VS DB отлично справляется с интеграцией изменений БД, внесенных другими членами команды, в ваш локальный проект / связанный БД. но вам нужно сделать дополнительный шаг, чтобы сравнить схему проекта с вашей локальной схемой dev db и применить моды. В этом есть смысл, но сначала это кажется неудобным.

DB Projects - очень мощный инструмент. Они не только создают сценарии, но и могут немедленно их применять. Будьте осторожны, чтобы не уничтожить им вашу производственную базу данных. ;)

Мне очень нравятся проекты VS DB, и я планирую использовать этот инструмент для всех моих проектов db в будущем.

+ Том

Вот пример решения для бедняков для триггера, реализующего отслеживание изменений в объектах db (с помощью операторов DDL) в базе данных sql server 2005/2008. Я также содержит простой пример того, как обеспечить использование необходимого тега someValue xml в исходном коде для каждой команды sql, выполняемой в базе данных + отслеживание текущей версии и типа базы данных (dev, test, qa, fb, prod ) Его можно расширить дополнительными обязательными атрибутами, такими как и т. д. Код довольно длинный - он создает пустую базу данных + необходимую структуру таблицы отслеживания + необходимые функции базы данных и триггер заполнения, все они выполняются по схеме [ga].

USE [master]
GO

/****** Object:  Database [DBGA_DEV]    Script Date: 04/22/2009 13:22:01 ******/
CREATE DATABASE [DBGA_DEV] ON  PRIMARY 
( NAME = N'DBGA_DEV', FILENAME = N'D:\GENAPP\DATA\DBFILES\DBGA_DEV.mdf' , SIZE = 3072KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )
 LOG ON 
( NAME = N'DBGA_DEV_log', FILENAME = N'D:\GENAPP\DATA\DBFILES\DBGA_DEV_log.ldf' , SIZE = 6208KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO

ALTER DATABASE [DBGA_DEV] SET COMPATIBILITY_LEVEL = 100
GO

IF (1 = FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
begin
EXEC [DBGA_DEV].[dbo].[sp_fulltext_database] @action = 'enable'
end
GO

ALTER DATABASE [DBGA_DEV] SET ANSI_NULL_DEFAULT OFF 
GO

ALTER DATABASE [DBGA_DEV] SET ANSI_NULLS OFF 
GO

ALTER DATABASE [DBGA_DEV] SET ANSI_PADDING ON 
GO

ALTER DATABASE [DBGA_DEV] SET ANSI_WARNINGS OFF 
GO

ALTER DATABASE [DBGA_DEV] SET ARITHABORT OFF 
GO

ALTER DATABASE [DBGA_DEV] SET AUTO_CLOSE OFF 
GO

ALTER DATABASE [DBGA_DEV] SET AUTO_CREATE_STATISTICS ON 
GO

ALTER DATABASE [DBGA_DEV] SET AUTO_SHRINK OFF 
GO

ALTER DATABASE [DBGA_DEV] SET AUTO_UPDATE_STATISTICS ON 
GO

ALTER DATABASE [DBGA_DEV] SET CURSOR_CLOSE_ON_COMMIT OFF 
GO

ALTER DATABASE [DBGA_DEV] SET CURSOR_DEFAULT  GLOBAL 
GO

ALTER DATABASE [DBGA_DEV] SET CONCAT_NULL_YIELDS_NULL OFF 
GO

ALTER DATABASE [DBGA_DEV] SET NUMERIC_ROUNDABORT OFF 
GO

ALTER DATABASE [DBGA_DEV] SET QUOTED_IDENTIFIER OFF 
GO

ALTER DATABASE [DBGA_DEV] SET RECURSIVE_TRIGGERS OFF 
GO

ALTER DATABASE [DBGA_DEV] SET  DISABLE_BROKER 
GO

ALTER DATABASE [DBGA_DEV] SET AUTO_UPDATE_STATISTICS_ASYNC OFF 
GO

ALTER DATABASE [DBGA_DEV] SET DATE_CORRELATION_OPTIMIZATION OFF 
GO

ALTER DATABASE [DBGA_DEV] SET TRUSTWORTHY OFF 
GO

ALTER DATABASE [DBGA_DEV] SET ALLOW_SNAPSHOT_ISOLATION OFF 
GO

ALTER DATABASE [DBGA_DEV] SET PARAMETERIZATION SIMPLE 
GO

ALTER DATABASE [DBGA_DEV] SET READ_COMMITTED_SNAPSHOT OFF 
GO

ALTER DATABASE [DBGA_DEV] SET HONOR_BROKER_PRIORITY OFF 
GO

ALTER DATABASE [DBGA_DEV] SET  READ_WRITE 
GO

ALTER DATABASE [DBGA_DEV] SET RECOVERY FULL 
GO

ALTER DATABASE [DBGA_DEV] SET  MULTI_USER 
GO

ALTER DATABASE [DBGA_DEV] SET PAGE_VERIFY CHECKSUM  
GO

ALTER DATABASE [DBGA_DEV] SET DB_CHAINING OFF 
GO

EXEC [DBGA_DEV].sys.sp_addextendedproperty @name=N'DbType', @value=N'DEV' 
GO

EXEC [DBGA_DEV].sys.sp_addextendedproperty @name=N'DbVersion', @value=N'0.0.1.20090414.1100' 
GO



USE [DBGA_DEV]
GO
/****** Object:  Schema [ga]    Script Date: 04/22/2009 13:21:29 ******/
CREATE SCHEMA [ga] AUTHORIZATION [dbo]
GO
EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'Contains the objects of the Generic Application database' , @level0type=N'SCHEMA',@level0name=N'ga'
GO
/****** Object:  Table [ga].[tb_DataMeta_ObjChangeLog]    Script Date: 04/22/2009 13:21:40 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [ga].[tb_DataMeta_ObjChangeLog](
    [LogId] [int] IDENTITY(1,1) NOT NULL,
    [TimeStamp] [timestamp] NOT NULL,
    [DatabaseName] [varchar](256) NOT NULL,
    [SchemaName] [varchar](256) NOT NULL,
    [DbVersion] [varchar](20) NOT NULL,
    [DbType] [varchar](20) NOT NULL,
    [EventType] [varchar](50) NOT NULL,
    [ObjectName] [varchar](256) NOT NULL,
    [ObjectType] [varchar](25) NOT NULL,
    [Version] [varchar](50) NULL,
    [SqlCommand] [varchar](max) NOT NULL,
    [EventDate] [datetime] NOT NULL,
    [LoginName] [varchar](256) NOT NULL,
    [FirstName] [varchar](256) NULL,
    [LastName] [varchar](50) NULL,
    [ChangeDescription] [varchar](1000) NULL,
    [Description] [varchar](1000) NULL,
    [ObjVersion] [varchar](20) NOT NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING ON
GO
EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'The database version as written in the extended prop of the database' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'TABLE',@level1name=N'tb_DataMeta_ObjChangeLog', @level2type=N'COLUMN',@level2name=N'DbVersion'
GO
EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'dev , test , qa , fb or prod' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'TABLE',@level1name=N'tb_DataMeta_ObjChangeLog', @level2type=N'COLUMN',@level2name=N'DbType'
GO
EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'The name of the object as it is registered in the sys.objects ' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'TABLE',@level1name=N'tb_DataMeta_ObjChangeLog', @level2type=N'COLUMN',@level2name=N'ObjectName'
GO
EXEC sys.sp_addextendedproperty @name=N'MS_Description', @value=N'' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'TABLE',@level1name=N'tb_DataMeta_ObjChangeLog', @level2type=N'COLUMN',@level2name=N'Description'
GO
SET IDENTITY_INSERT [ga].[tb_DataMeta_ObjChangeLog] ON
INSERT [ga].[tb_DataMeta_ObjChangeLog] ([LogId], [DatabaseName], [SchemaName], [DbVersion], [DbType], [EventType], [ObjectName], [ObjectType], [Version], [SqlCommand], [EventDate], [LoginName], [FirstName], [LastName], [ChangeDescription], [Description], [ObjVersion]) VALUES (3, N'DBGA_DEV', N'en', N'0.0.1.20090414.1100', N'DEV', N'DROP_TABLE', N'tb_BL_Products', N'TABLE', N' some', N'<EVENT_INSTANCE><EventType>DROP_TABLE</EventType><PostTime>2009-04-22T11:03:11.880</PostTime><SPID>57</SPID><ServerName>YSG</ServerName><LoginName>ysg\yordgeor</LoginName><UserName>dbo</UserName><DatabaseName>DBGA_DEV</DatabaseName><SchemaName>en</SchemaName><ObjectName>tb_BL_Products</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS = "ON" ANSI_NULL_DEFAULT = "ON" ANSI_PADDING = "ON" QUOTED_IDENTIFIER = "ON" ENCRYPTED = "FALSE"/><CommandText>drop TABLE [en].[tb_BL_Products] --<Version> some</Version>&#x0D;
</CommandText></TSQLCommand></EVENT_INSTANCE>', CAST(0x00009BF300B6271C AS DateTime), N'ysg\yordgeor', N'Yordan', N'Georgiev', NULL, NULL, N'0.0.0')
INSERT [ga].[tb_DataMeta_ObjChangeLog] ([LogId], [DatabaseName], [SchemaName], [DbVersion], [DbType], [EventType], [ObjectName], [ObjectType], [Version], [SqlCommand], [EventDate], [LoginName], [FirstName], [LastName], [ChangeDescription], [Description], [ObjVersion]) VALUES (4, N'DBGA_DEV', N'en', N'0.0.1.20090414.1100', N'DEV', N'CREATE_TABLE', N'tb_BL_Products', N'TABLE', N' 2.2.2 ', N'<EVENT_INSTANCE><EventType>CREATE_TABLE</EventType><PostTime>2009-04-22T11:03:18.620</PostTime><SPID>57</SPID><ServerName>YSG</ServerName><LoginName>ysg\yordgeor</LoginName><UserName>dbo</UserName><DatabaseName>DBGA_DEV</DatabaseName><SchemaName>en</SchemaName><ObjectName>tb_BL_Products</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS = "ON" ANSI_NULL_DEFAULT = "ON" ANSI_PADDING = "ON" QUOTED_IDENTIFIER = "ON" ENCRYPTED = "FALSE"/><CommandText>CREATE TABLE [en].[tb_BL_Products](&#x0D;
    [ProducId] [int] NULL,&#x0D;
    [ProductName] [nchar](10) NULL,&#x0D;
    [ProductDescription] [varchar](5000) NULL&#x0D;
) ON [PRIMARY]&#x0D;
/*&#x0D;
<Version> 2.2.2 </Version>&#x0D;
&#x0D;
*/&#x0D;
</CommandText></TSQLCommand></EVENT_INSTANCE>', CAST(0x00009BF300B62F07 AS DateTime), N'ysg\yordgeor', N'Yordan', N'Georgiev', NULL, NULL, N'0.0.0')
INSERT [ga].[tb_DataMeta_ObjChangeLog] ([LogId], [DatabaseName], [SchemaName], [DbVersion], [DbType], [EventType], [ObjectName], [ObjectType], [Version], [SqlCommand], [EventDate], [LoginName], [FirstName], [LastName], [ChangeDescription], [Description], [ObjVersion]) VALUES (5, N'DBGA_DEV', N'en', N'0.0.1.20090414.1100', N'DEV', N'DROP_TABLE', N'tb_BL_Products', N'TABLE', N' 2.2.2 ', N'<EVENT_INSTANCE><EventType>DROP_TABLE</EventType><PostTime>2009-04-22T11:25:12.620</PostTime><SPID>57</SPID><ServerName>YSG</ServerName><LoginName>ysg\yordgeor</LoginName><UserName>dbo</UserName><DatabaseName>DBGA_DEV</DatabaseName><SchemaName>en</SchemaName><ObjectName>tb_BL_Products</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS = "ON" ANSI_NULL_DEFAULT = "ON" ANSI_PADDING = "ON" QUOTED_IDENTIFIER = "ON" ENCRYPTED = "FALSE"/><CommandText>drop TABLE [en].[tb_BL_Products] &#x0D;
</CommandText></TSQLCommand></EVENT_INSTANCE>', CAST(0x00009BF300BC32F1 AS DateTime), N'ysg\yordgeor', N'Yordan', N'Georgiev', NULL, NULL, N'0.0.0')
INSERT [ga].[tb_DataMeta_ObjChangeLog] ([LogId], [DatabaseName], [SchemaName], [DbVersion], [DbType], [EventType], [ObjectName], [ObjectType], [Version], [SqlCommand], [EventDate], [LoginName], [FirstName], [LastName], [ChangeDescription], [Description], [ObjVersion]) VALUES (6, N'DBGA_DEV', N'en', N'0.0.1.20090414.1100', N'DEV', N'CREATE_TABLE', N'tb_BL_Products', N'TABLE', N' 2.2.2 ', N'<EVENT_INSTANCE><EventType>CREATE_TABLE</EventType><PostTime>2009-04-22T11:25:19.053</PostTime><SPID>57</SPID><ServerName>YSG</ServerName><LoginName>ysg\yordgeor</LoginName><UserName>dbo</UserName><DatabaseName>DBGA_DEV</DatabaseName><SchemaName>en</SchemaName><ObjectName>tb_BL_Products</ObjectName><ObjectType>TABLE</ObjectType><TSQLCommand><SetOptions ANSI_NULLS = "ON" ANSI_NULL_DEFAULT = "ON" ANSI_PADDING = "ON" QUOTED_IDENTIFIER = "ON" ENCRYPTED = "FALSE"/><CommandText>CREATE TABLE [en].[tb_BL_Products](&#x0D;
    [ProducId] [int] NULL,&#x0D;
    [ProductName] [nchar](10) NULL,&#x0D;
    [ProductDescription] [varchar](5000) NULL&#x0D;
) ON [PRIMARY]&#x0D;
/*&#x0D;
<Version> 2.2.2 </Version>&#x0D;
&#x0D;
*/&#x0D;
</CommandText></TSQLCommand></EVENT_INSTANCE>', CAST(0x00009BF300BC3A69 AS DateTime), N'ysg\yordgeor', N'Yordan', N'Georgiev', NULL, NULL, N'0.0.0')
SET IDENTITY_INSERT [ga].[tb_DataMeta_ObjChangeLog] OFF
/****** Object:  Table [ga].[tb_BLSec_LoginsForUsers]    Script Date: 04/22/2009 13:21:40 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [ga].[tb_BLSec_LoginsForUsers](
    [LoginsForUsersId] [int] IDENTITY(1,1) NOT NULL,
    [LoginName] [nvarchar](100) NOT NULL,
    [FirstName] [varchar](100) NOT NULL,
    [SecondName] [varchar](100) NULL,
    [LastName] [varchar](100) NOT NULL,
    [DomainName] [varchar](100) NOT NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING ON
GO
SET IDENTITY_INSERT [ga].[tb_BLSec_LoginsForUsers] ON
INSERT [ga].[tb_BLSec_LoginsForUsers] ([LoginsForUsersId], [LoginName], [FirstName], [SecondName], [LastName], [DomainName]) VALUES (1, N'ysg\yordgeor', N'Yordan', N'Stanchev', N'Georgiev', N'yordgeor')
SET IDENTITY_INSERT [ga].[tb_BLSec_LoginsForUsers] OFF
/****** Object:  Table [en].[tb_BL_Products]    Script Date: 04/22/2009 13:21:40 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [en].[tb_BL_Products](
    [ProducId] [int] NULL,
    [ProductName] [nchar](10) NULL,
    [ProductDescription] [varchar](5000) NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING ON
GO
/****** Object:  StoredProcedure [ga].[procUtils_SqlCheatSheet]    Script Date: 04/22/2009 13:21:37 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [ga].[procUtils_SqlCheatSheet]                

as                 
set nocount on                 

--what was the name of the table with something like role                
/*                
SELECT * from sys.tables where [name] like '%POC%'                
*/                
-- what are the columns of this table                 
/*                
select column_name , DATA_TYPE , CHARACTER_MAXIMUM_LENGTH,  table_name  from Information_schema.columns where table_name='tbGui_ExecutePOC'                
*/                

-- find proc        
--what was the name of procedure with something like role                
/*                
select * from sys.procedures where [name] like '%ext%'                
exec sp_HelpText procName        
*/                
/*                
exec sp_helpText procUtils_InsertGenerator                
*/                
--how to list all databases in sql server                 
/*                
SELECT database_id AS ID, NULL AS ParentID, name AS Text FROM sys.databases ORDER BY [name]                
*/                

--HOW-TO LIST ALL TABLES IN A SQL SERVER 2005 DATABASE                
/*                
SELECT TABLE_NAME FROM [POC].INFORMATION_SCHEMA.TABLES                
WHERE TABLE_TYPE = 'BASE TABLE'                  
AND TABLE_NAME <> 'dtproperties'                  
ORDER BY TABLE_NAME                


*/                
--HOW-TO ENABLE XP_CMDSHELL START                
-------------------------------------------------------------------------                
-- configure verbose mode temporarily                 
-- EXECUTE sp_configure 'show advanced options', 1                 
-- RECONFIGURE WITH OVERRIDE                 
--GO                 


--ENABLE xp_cmdshell                 
-- EXECUTE sp_configure 'xp_cmdshell', '1'                 
-- RECONFIGURE WITH OVERRIDE                 
-- EXEC SP_CONFIGURE 'show advanced option', '1';                 
-- SHOW THE CONFIGURATION                 
-- EXEC SP_CONFIGURE;                 


--turn show advance options off                 
-- GO                 
--EXECUTE sp_configure 'show advanced options', 0                 
-- RECONFIGURE WITH OVERRIDE                 
-- GO                

--HOW-TO ENABLE XP_CMDSHELL END                
-------------------------------------------------------------------------                

--HOW-TO IMPLEMENT SLEEP                 
-- sleep for 10 seconds                 
-- WAITFOR DELAY '00:00:10' SELECT * FROM My_Table                

/* LIST ALL PRIMARY KEYS                 

SELECT                 
  INFORMATION_SCHEMA.TABLE_CONSTRAINTS.TABLE_NAME AS TABLE_NAME,                
  INFORMATION_SCHEMA.KEY_COLUMN_USAGE.COLUMN_NAME AS COLUMN_NAME,                 
  REPLACE(INFORMATION_SCHEMA.TABLE_CONSTRAINTS.CONSTRAINT_TYPE,' ', '_') AS CONSTRAINT_TYPE                 
FROM                 
  INFORMATION_SCHEMA.TABLE_CONSTRAINTS                 
  INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE ON                 
  INFORMATION_SCHEMA.TABLE_CONSTRAINTS.CONSTRAINT_NAME =                 
  INFORMATION_SCHEMA.KEY_COLUMN_USAGE.CONSTRAINT_NAME                 
WHERE                 
  INFORMATION_SCHEMA.TABLE_CONSTRAINTS.TABLE_NAME <> N'sysdiagrams'                 
ORDER BY                 
  INFORMATION_SCHEMA.TABLE_CONSTRAINTS.TABLE_NAME ASC                

*/                

--HOW-TO COPY TABLE AND THE WHOLE TABLE DATA , COPY TABLE FROM DB TO DB                
--==================================================START                 
/*                
use Poc_Dev                
go                
drop table tbGui_LinksVisibility                

use POc_test                
go                
select *                 
INTO [POC_Dev].[ga].[tbGui_LinksVisibility]                
from [POC_TEST].[ga].[tbGui_LinksVisibility]                


*/                
--HOW-TO COPY TABLE AND THE WHOLE TABLE DATA , COPY TABLE FROM DB TO DB                
--====================================================END                
--=================================================== SEE TABLE METADATA START                
/*                



SELECT c.name AS [COLUMN_NAME], sc.data_type AS [DATA_TYPE], [value] AS                 
[DESCRIPTION] , c.max_length as [MAX_LENGTH] , c.is_nullable AS [OPTIONAL]                 
, c.is_identity AS [IS_PRIMARY_KEY] FROM sys.extended_properties AS ep                 
INNER JOIN sys.tables AS t ON ep.major_id = t.object_id                 
INNER JOIN sys.columns AS c ON ep.major_id = c.object_id AND ep.minor_id                 
= c.column_id                 
INNER JOIN INFORMATION_SCHEMA.COLUMNS sc ON t.name = sc.table_name and                 
c.name = sc.column_name                 
WHERE class = 1 and t.name = 'tbGui_ExecutePOC' ORDER BY SC.DATA_TYPE                


*/                
--=================================================== SEE TABLE METADATA END               
    /*            
select * from Information_schema.columns                
select table_name , column_name from Information_schema.columns where table_name='tbGui_Wizards'                
    */            


--=================================================== LIST ALL TABLES AND THEIR DESCRIPTOINS START                
/*                

SELECT T.name AS TableName, CAST(Props.value AS varchar(1000)) AS                
TableDescription                
FROM sys.tables AS T LEFT OUTER JOIN                
(SELECT class, class_desc, major_id, minor_id,                
name, value                
FROM sys.extended_properties                
WHERE (minor_id = 0) AND (class = 1)) AS                
Props ON T.object_id = Props.major_id                
WHERE (T.type = 'U') AND (T.name <> N'sysdiagrams')                
ORDER BY TableName                
*/                
--=================================================== LIST ALL TABLES AND THEIR DESCRIPTOINS START                

--=================================================== LIST ALL OBJECTS FROM DB START                
/*                


use DB                
--HOW-TO LIST ALL PROCEDURE IN A DATABASE                
select s.name from sysobjects s where type = 'P'                
--HOW-TO LIST ALL TRIGGERS BY NAME IN A DATABASE                
select s.name from sysobjects s where type = 'TR'                
--HOW-TO LIST TABLES IN A DATABASE                 
select s.name from sysobjects s where type = 'U'                
--how-to list all system tables in a database                
select s.name from sysobjects s where type = 's'                
--how-to list all the views in a database                
select s.name from sysobjects s where type = 'v'                


*/                

/*                
Similarly you can find out other objects created by user, simple change type =                 

C = CHECK constraint                 

D = Default or DEFAULT constraint                 

F = FOREIGN KEY constraint                 

L = Log                 

FN = Scalar function                 

IF = In-lined table-function                 

P = Stored procedure                 

PK = PRIMARY KEY constraint (type is K)                 

RF = Replication filter stored procedure                

S = System table                 

TF = Table function                 

TR = Trigger                 

U = User table ( this is the one I discussed above in the example)                

UQ = UNIQUE constraint (type is K)                 

V = View                 

X = Extended stored procedure                
*/                



--=================================================== HOW-TO SEE ALL MY PERMISSIONS START                


/*                

SELECT * FROM fn_my_permissions(NULL, 'SERVER');                
USE poc_qa;                
SELECT * FROM fn_my_permissions (NULL, 'database');                
GO                

*/                
--=================================================== HOW-TO SEE ALL MY PERMISSIONS END                

/*               
--find table               

use poc_dev               
go               
select s.name from sysobjects s where type = 'u'  and s.name like '%Visibility%'              
select * from tbGui_LinksVisibility              

*/              

/* find cursor              

use poc      
go        
DECLARE @procName varchar(100)        
DECLARE @cursorProcNames CURSOR        
SET @cursorProcNames = CURSOR FOR        
select name from sys.procedures where modify_date > '2009-02-05 13:12:15.273' order by modify_date desc       

OPEN @cursorProcNames        
FETCH NEXT        
FROM @cursorProcNames INTO @procName        
WHILE @@FETCH_STATUS = 0        
BEGIN        

set nocount off;        
exec sp_HelpText @procName --- or print them        
-- print @procName        

FETCH NEXT        
FROM @cursorProcNames INTO @procName        
END        
CLOSE @cursorProcNames        

select @@error    

*/              


/* --  SEE STORED PROCEDURE EXT PROPS            

SELECT ep.name as 'EXT_PROP_NAME' , SP.NAME , [value] as 'DESCRIPTION' FROM sys.extended_properties as ep left join sys.procedures as sp on sp.object_id = ep.major_id where sp.type='P'            


-- what the hell I ve been doing lately on sql server 2005 / 2008
select o.name , 
(SELECT [definition] AS [text()] FROM sys.all_sql_modules where sys.all_sql_modules.object_id=a.object_id FOR XML PATH(''), TYPE) AS Statement_Text
, a.object_id, o.modify_date from sys.all_sql_modules a left join sys.objects o on a.object_id=o.object_id order by 4 desc



-- GET THE RIGHT LANG SCHEMA START 
DECLARE @template AS varchar(max)
SET @template = 'SELECT * FROM {object_name}'

DECLARE @object_name AS sysname

SELECT @object_name = QUOTENAME(s.name) + '.' + QUOTENAME(o.name)
FROM sys.objects o
INNER JOIN sys.schemas s
    ON s.schema_id = o.schema_id
WHERE o.object_id = OBJECT_ID(QUOTENAME(@LANG) + '.[TestingLanguagesInNameSpacesDelMe]')

IF @object_name IS NOT NULL
BEGIN
    DECLARE @sql AS varchar(max)
    SET @sql = REPLACE(@template, '{object_name}', @object_name)
    EXEC (@sql)
END
-- GET THE RIGHT LANG SCHEMA END 

--  SEE STORED PROCEDURE EXT PROPS end*/             
set nocount off
GO
EXEC sys.sp_addextendedproperty @name=N'AuthorName', @value=N'Yordan Georgiev' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'PROCEDURE',@level1name=N'procUtils_SqlCheatSheet'
GO
EXEC sys.sp_addextendedproperty @name=N'ProcDescription', @value=N'TODO:ADD HERE DESCRPIPTION' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'PROCEDURE',@level1name=N'procUtils_SqlCheatSheet'
GO
EXEC sys.sp_addextendedproperty @name=N'ProcVersion', @value=N'0.1.0.20090406.1317' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'PROCEDURE',@level1name=N'procUtils_SqlCheatSheet'
GO
/****** Object:  UserDefinedFunction [ga].[GetDbVersion]    Script Date: 04/22/2009 13:21:42 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE FUNCTION [ga].[GetDbVersion]()
RETURNS VARCHAR(20)
    BEGIN
        RETURN convert(varchar(20) , (select value from sys.extended_properties where name='DbVersion' and class_desc='DATABASE') )
    END
GO
EXEC sys.sp_addextendedproperty @name=N'AuthorName', @value=N'Yordan Georgiev' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'FUNCTION',@level1name=N'GetDbVersion'
GO
EXEC sys.sp_addextendedproperty @name=N'ChangeDescription', @value=N'Initial creation' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'FUNCTION',@level1name=N'GetDbVersion'
GO
EXEC sys.sp_addextendedproperty @name=N'CreatedWhen', @value=N'getDate()' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'FUNCTION',@level1name=N'GetDbVersion'
GO
EXEC sys.sp_addextendedproperty @name=N'Description', @value=N'Gets the current version of the database ' , @level0type=N'SCHEMA',@level0name=N'ga', @level1type=N'FUNCTION',@level1name=N'GetDbVersion'
GO
/****** Object:  UserDefinedFunction [ga].[GetDbType]    Script Date: 04/22/2009 13:21:42 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE FUNCTION [ga].[GetDbType]()
RETURNS VARCHAR(30)
    BEGIN
        RETURN convert(varchar(30) , (select value from sys.extended_properties where name='DbType' and class_desc='DATABASE') )
    END
GO
/****** Object:  Default [DF_tb_DataMeta_ObjChangeLog_DbVersion]    Script Date: 04/22/2009 13:21:40 ******/
ALTER TABLE [ga].[tb_DataMeta_ObjChangeLog] ADD  CONSTRAINT [DF_tb_DataMeta_ObjChangeLog_DbVersion]  DEFAULT ('select ga.GetDbVersion()') FOR [DbVersion]
GO
/****** Object:  Default [DF_tb_DataMeta_ObjChangeLog_EventDate]    Script Date: 04/22/2009 13:21:40 ******/
ALTER TABLE [ga].[tb_DataMeta_ObjChangeLog] ADD  CONSTRAINT [DF_tb_DataMeta_ObjChangeLog_EventDate]  DEFAULT (getdate()) FOR [EventDate]
GO
/****** Object:  Default [DF_tb_DataMeta_ObjChangeLog_ObjVersion]    Script Date: 04/22/2009 13:21:40 ******/
ALTER TABLE [ga].[tb_DataMeta_ObjChangeLog] ADD  CONSTRAINT [DF_tb_DataMeta_ObjChangeLog_ObjVersion]  DEFAULT ('0.0.0') FOR [ObjVersion]
GO
/****** Object:  DdlTrigger [trigMetaDoc_TraceDbChanges]    Script Date: 04/22/2009 13:21:29 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
create trigger [trigMetaDoc_TraceDbChanges]
on database
for create_procedure, alter_procedure, drop_procedure,
create_table, alter_table, drop_table,
create_function, alter_function, drop_function , 
create_trigger , alter_trigger , drop_trigger 
as

set nocount on

declare @data xml
set @data = EVENTDATA()
declare @DbVersion varchar(20)
set @DbVersion =(select ga.GetDbVersion())
declare @DbType varchar(20)
set @DbType =(select ga.GetDbType())
declare @DbName varchar(256)
set @DbName [email protected]('(/EVENT_INSTANCE/DatabaseName)[1]', 'varchar(256)')
declare @EventType varchar(256)
set @EventType [email protected]('(/EVENT_INSTANCE/EventType)[1]', 'varchar(50)')
declare @ObjectName varchar(256)
set @ObjectName  = @data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'varchar(256)')
declare @ObjectType varchar(25)
set @ObjectType = @data.value('(/EVENT_INSTANCE/ObjectType)[1]', 'varchar(25)')
declare @TSQLCommand varchar(max)
set @TSQLCommand = @data.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'varchar(max)')
declare @opentag varchar(4)
set @opentag= '&lt;'
declare @closetag varchar(4) 
set @closetag= '&gt;'
declare @newDataTxt varchar(max) 
set @newDataTxt= cast(@data as varchar(max))
set @newDataTxt = REPLACE ( REPLACE(@newDataTxt , @opentag , '<') , @closetag , '>')
-- print @newDataTxt
declare @newDataXml xml 
set @newDataXml = CONVERT ( xml , @newDataTxt)
declare @Version varchar(50)
set @Version = @newDataXml.value('(/EVENT_INSTANCE/TSQLCommand/CommandText/Version)[1]', 'varchar(50)')

-- if we are dropping take the version from the existing object 
if  ( SUBSTRING(@EventType , 0 , 5)) = 'DROP'
set @Version =( select top 1 [Version]  from ga.tb_DataMeta_ObjChangeLog where ObjectName=@ObjectName order by [LogId] desc)



declare @LoginName varchar(256) 
set @LoginName = @data.value('(/EVENT_INSTANCE/LoginName)[1]', 'varchar(256)')
declare @FirstName varchar(50)
set @FirstName= (select [FirstName] from [ga].[tb_BLSec_LoginsForUsers] where [LoginName] = @LoginName)
declare @LastName varchar(50)
set @LastName  = (select [LastName] from [ga].[tb_BLSec_LoginsForUsers] where [LoginName] = @LoginName)
declare @SchemaName sysname 
set @SchemaName = @data.value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname');
--declare @Description xml 
--set @Description = @data.query('(/EVENT_INSTANCE/TSQLCommand/text())')




--print 'VERSION IS ' + @Version
--print @newDataTxt
--print cast(@data as varchar(max))


-- select column_name from information_schema.columns where table_name ='tb_DataMeta_ObjChangeLog'
insert into [ga].[tb_DataMeta_ObjChangeLog]
(
[DatabaseName] ,
[SchemaName],
[DbVersion] ,
[DbType],
[EventType],
[ObjectName],
[ObjectType] ,
[Version],
[SqlCommand] ,
[LoginName] ,
[FirstName],
[LastName] 
)

values(

@DbName,
@SchemaName,
@DbVersion,
@DbType,
@EventType, 
@ObjectName, 
@ObjectType , 
@Version,
@newDataTxt, 
@LoginName , 
@FirstName , 
@LastName
)
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
DISABLE TRIGGER [trigMetaDoc_TraceDbChanges] ON DATABASE
GO
/****** Object:  DdlTrigger [trigMetaDoc_TraceDbChanges]    Script Date: 04/22/2009 13:21:29 ******/
Enable Trigger [trigMetaDoc_TraceDbChanges] ON Database
GO

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

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

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

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

Я использую SchemaBank для управления версиями всех изменений схемы моей базы данных:

• с первого дня я импортирую в него дамп схемы базы данных
• я начал менять дизайн схемы с помощью веб-браузера (потому что они SaaS / облачные)
• когда я хочу обновить свой сервер БД, я генерирую из него сценарий изменения (SQL) и применяю его к БД. В Schemabank мне поручили зафиксировать мою работу как версию, прежде чем я смогу сгенерировать скрипт обновления. Мне нравится такая практика, так что я всегда могу отследить, когда мне нужно.

Правило нашей команды: НИКОГДА не прикасайтесь к серверу db напрямую, не сохранив предварительно проектную работу. Но бывает, что кто-то может соблазниться нарушить правило ради удобства. Мы бы снова импортировали дамп схемы в schemabank и позволили бы ему выполнить различие и вышибить кого-нибудь, если будет обнаружено несоответствие. Хотя мы могли бы сгенерировать из него сценарии изменения, чтобы синхронизировать нашу базу данных и схему, нам это просто не нравится.

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

Довольно удобный веб-инструмент для разработки схем с контролем версий и управлением изменениями.

К сожалению, я видел не одну команду, разрабатывающую программы PL / SQL (хранимые процедуры в Oracle) - иногда десятки тысяч LOC - просто редактируя код в TOAD (инструмент базы данных), даже не сохраняя исходный код в файлы (за исключением развертывание). Даже если для базы данных выполняется регулярное резервное копирование (хотя я бы не стал воспринимать это как должное), единственный способ получить старую версию хранимой процедуры - это восстановить всю базу данных, размер которой составляет много ГБ. И, конечно, иногда одновременные изменения в одном файле приводят к потере работы, когда над одним проектом работают несколько разработчиков.

«Краткая версия: сбросьте свою производственную базу данных в репозиторий git для мгновенного резервного копирования.»

Я считаю, что каждая БД должна находиться под контролем источника, и у разработчиков должен быть простой способ создать свою локальную базу данных с нуля. Вдохновленный Visual Studio для специалистов по базам данных, я создал инструмент с открытым исходным кодом, который создает сценарии для баз данных MS SQL и предоставляет простой способ их развертывания на вашем локальном движке БД. Попробуйте http://dbsourcetools.codeplex.com/. Веселиться, - Натан.

Я использую ActiveRecord Migrations. Этот драгоценный камень Ruby можно использовать вне проекта Rails, и существуют адаптеры для обработки большинства баз данных, с которыми вы столкнетесь. Мой совет: если вы можете запустить свой проект в Postgres, вы получите миграции транзакционной схемы. Это означает, что вы не получите сломанную базу данных, если миграция применяется только наполовину.

Одним из основных вариантов использования Kira является обновление базы данных путем явного указания схемы вне базы данных в виде кода. Затем он может управлять базой данных и обновлять ее до любой версии с любой версии.

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

Если ваша база данных - 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.

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

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

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

Извиняюсь за откровенную саморекламу, но надеюсь, это кому-то пригодится!

Для oracle я использую самописную java-программу Oracle-DDL 2 SVN для автоматического отслеживания изменений схемы DDL Oracle в SVN

Я согласен со многими сообщениями, касающимися миграции Ruby ActiveRecord - это элегантный способ управления базой данных в небольших дополнительных файлах, которыми может поделиться каждый. С учетом сказанного, я недавно реализовал проект с использованием VisualStudio Database Project, и это вроде как заставило меня поверить в это. Краткая история - вы создаете проект базы данных, импортируете в него все (если есть) существующие объекты базы данных (таблицы / представления / триггеры / ключи / пользователи / и т. д.). Этот импорт приводит к созданию сценария «Создать» для каждого объекта. Для управления базой данных вы изменяете сценарий создания, а затем при развертывании VS сравнивает целевую базу данных с состоянием базы данных, находящейся в вашем проекте, и применяете соответствующие операторы изменения.

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

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

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

Что касается операторов CREATE, DROP, ALTER и т. д. (DDL), мы разработали и использовали BuildMaster для управления развертыванием этих сценариев, чтобы их можно было запускать один и только один раз для целевой базы данных (независимо от того, не работают они или нет). Общая идея заключается в том, что разработчики загружают сценарии изменений в систему, и когда придет время развертывания, будут запущены только сценарии изменений, которые не были запущены в базе данных целевой среды (это управляется очень аналогично Ответ самодержавия). Причина такого разделения типов скриптов заключается в том, что после того, как вы манипулируете структурой таблицы, добавляете индекс и т. д., Вы не можете отменить это, не написав совершенно новый скрипт или не восстановив базу данных - в отличие от объектного кода, в котором вы можно просто удалить представление или хранимую процедуру, а затем воссоздать ее.

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

Я слышал, как люди говорят, что схемы обязательно должны храниться в базе данных. Я не уверен, что согласен. Это действительно зависит от системы, с которой вы работаете. Если ваша система относительно мала и данные не так уж и важны. И скорость, с которой вам нужно вывести другую среду разработки в онлайн, имеет решающее значение ... тогда да ... вы можете извлечь из этого выгоду. Однако, когда ваша схема бесполезна без данных, а база данных чрезвычайно велика, становится практически невозможно «контролировать исходный код» вашей базы данных. Конечно, вы все еще можете хранить свой DDL-код в системе управления версиями, но это бесполезно. Вы не можете получить необходимые данные без резервного копирования / восстановления.

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

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

Вот краткий список инструментов, которые контролируют версии базы данных, я перечислил плюсы и минусы каждого (полное раскрытие: я работаю в DBmaestro)

Red-Gate - на рынке много лет. Он обеспечивает контроль версий объектов базы данных с помощью скриптов, интегрированных с файловым управлением версиями.

DBVS - обеспечивает контроль версий объектов базы данных с помощью скриптов, интегрированных с файловым контролем версий.

DBmaestro - обеспечивает принудительное применение процессов контроля версий (извлечение / возврат) к реальным объектам базы данных. Таким образом, нет никаких сомнений в том, что репозиторий управления версиями синхронизирован с базой данных, используемой приложением.

Я рекомендую вам прочитать исчерпывающий и беспристрастный обзор решений по принудительному управлению изменениями баз данных, подготовленный опытным экспертом по базам данных Беном Тейлором, который он опубликовал в LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro.

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

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

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

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

Ух ты, столько ответов. Для надежного управления версиями базы данных вам необходимо управлять версиями кода, который изменяет вашу базу данных. Некоторые CMS предлагают инструменты управления конфигурацией, такие как тот, что есть в Drupal 8. Вот обзор с практическими шагами по упорядочить рабочий процесс и обеспечить версионность конфигурации базы данных, даже в командных средах: