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

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

В некоторых конкретных случаях вы можете сделать лучше, чем это -

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

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

Вероятно, это избыток для коротких документов (что-то под 100 КБ?).

589
задан 5 revs, 3 users 100% 1 March 2012 в 21:20
поделиться

50 ответов

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

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

382
ответ дан 5 revs, 4 users 73% 1 March 2012 в 21:20
поделиться

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

2
ответ дан Steve Moyer 1 March 2012 в 21:20
поделиться

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

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

2
ответ дан Robert S. 1 March 2012 в 21:20
поделиться

У нас есть наш Создающий/Изменяющий сценарии при управлении исходным кодом. Что касается самой базы данных, когда у Вас есть сотни таблиц и большая обработка данных каждый минуты, это был бы ЦП и уничтожитель жесткого диска для управления версиями всей базы данных. Вот почему резервное копирование все еще, согласно мне, лучший способ управлять Вашими данными.

2
ответ дан David 1 March 2012 в 21:20
поделиться

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

2
ответ дан Adam Gibbins 1 March 2012 в 21:20
поделиться

Программное обеспечение RedGate делает некоторые большие инструменты, которые помогут Вам присвоить версию своей базе данных. Обязательно попытайтесь иметь Ваш devs, создают их собственные изолированные локальные базы данных для работы dev, а не полагаются "dev сервер", который может или не может снизиться в некоторое время.

2
ответ дан Karthik Hariharan 1 March 2012 в 21:20
поделиться

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

2
ответ дан user20620 1 March 2012 в 21:20
поделиться

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

2
ответ дан user14808 1 March 2012 в 21:20
поделиться

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

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

1
ответ дан Oli 1 March 2012 в 21:20
поделиться

Я управление версиями создать сценарий, и я использую 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  

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

);

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

1
ответ дан Autocracy 1 March 2012 в 21:20
поделиться

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

0
ответ дан dacracot 1 March 2012 в 21:20
поделиться

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

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

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

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

0
ответ дан tal 1 March 2012 в 21:20
поделиться

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

0
ответ дан 2 revs 1 March 2012 в 21:20
поделиться

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

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

0
ответ дан pearcewg 1 March 2012 в 21:20
поделиться

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

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

0
ответ дан Matt Jenkins 1 March 2012 в 21:20
поделиться

К вашему сведению Это было также поднято несколько дней назад Dana... Сохраненная схема процедур/DB в управлении исходным кодом

3
ответ дан 2 revs 1 March 2012 в 21:20
поделиться

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

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

3
ответ дан Tom Anderson 1 March 2012 в 21:20
поделиться

Сами базы данных? Никакой

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

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

133
ответ дан blowdart 1 March 2012 в 21:20
поделиться

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

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

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

36
ответ дан 2 revs, 2 users 89% 1 March 2012 в 21:20
поделиться

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

33
ответ дан killdash10 1 March 2012 в 21:20
поделиться

Вы никогда не должны просто входить в систему и начинать вводить команды "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

я уверен, что существует лучший способ сделать это, но он работал на меня до сих пор.

29
ответ дан Paul Tomblin 1 March 2012 в 21:20
поделиться

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

18
ответ дан Stu Thompson 1 March 2012 в 21:20
поделиться

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

я полагаю, что это было сделано с NaNt/CruiseControl.

14
ответ дан Sara Chipps 1 March 2012 в 21:20
поделиться

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

В Ruby on Rails, это обрабатывается платформой с "миграциями". Любое время Вы изменяете дб, Вы делаете сценарий, который применяет изменения, и проверьте его в управлении исходным кодом.

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

11
ответ дан 2 revs 1 March 2012 в 21:20
поделиться

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

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

схема дб "измельчена" для создания многих, многих маленьких .sql файлов, один на команду DDL, которая описывает DB.

<час> +tom

Дополнительная информация 30.11.2008

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

, поскольку схема "измельчена" в sql файлы, управление исходным кодом хорошо работает.

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

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

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

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

+tom

8
ответ дан 4 revs 1 March 2012 в 21:20
поделиться

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

6
ответ дан Paco 1 March 2012 в 21:20
поделиться

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

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

Плюс, SQL тогда отмечен наряду с Вашим исходным кодом, который идет с ним.

6
ответ дан DustinB 1 March 2012 в 21:20
поделиться

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

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

6
ответ дан Mike Deck 1 March 2012 в 21:20
поделиться

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

6
ответ дан HLGEM 1 March 2012 в 21:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: