В общем, вы не можете; вам нужно снова написать весь файл (по крайней мере, с точки зрения изменения до конца).
В некоторых конкретных случаях вы можете сделать лучше, чем это -
, если все ваши данные элементы имеют одинаковую длину и в определенном порядке, и вы знаете смещение того, с которым хотите избавиться, вы можете скопировать последний элемент над тем, который нужно удалить, и обрезать файл до последнего элемента;
, или вы можете просто перезаписать блок данных значением «это плохие данные, пропустить его» или оставить флаг «этот элемент удален» в ваших сохраненных элементах данных, чтобы вы могли пометить его удалением без изменения файл.
Вероятно, это избыток для коротких документов (что-то под 100 КБ?).
Необходимо прочитать Получить вашу базу данных под управлением версиями . Проверьте серию сообщений К. Скотта Аллена.
Когда дело доходит до контроля версий, база данных часто является гражданином второго или даже третьего сорта. Из того, что я видел, команды, которые никогда бы не подумали о написании кода без контроля версий через миллион лет - и это справедливо - могут каким-то образом совершенно не обращать внимания на необходимость контроля версий критически важных баз данных, на которые полагаются их приложения. Я не знаю, как вы можете называть себя инженером-программистом и вести себя открыто, когда ваша база данных находится не на том же строгом уровне контроля исходного кода, что и остальная часть вашего кода. Не позволяй этому случиться с тобой. Получите вашу базу данных под контролем версий.
Да... наши базы данных разработаны в ERwin, и DDLs для каждой версии автоматически сгенерированы. Файлы ERwin сохранены в нашей системе управления исходным кодом (на самом деле, так наши технические документы).
Мы используем репликацию и кластеризацию для управления нашими базами данных, а также для резервного копирования. Мы используем Serena для управления нашими сценариями SQL и реализацией конфигурации. Перед внесением изменений в конфигурацию мы выполняем резервное копирование как часть процесса управления изменениями. Эта резервная копия удовлетворяет нашему требованию отката.
Я думаю, что все зависит от масштаба. Вы говорите о корпоративных приложениях, которые нуждаются в резервном копировании и удаленном восстановлении? Небольшая рабочая группа, работающая с бухгалтерским приложением? Или где-то посередине?
У нас есть наш Создающий/Изменяющий сценарии при управлении исходным кодом. Что касается самой базы данных, когда у Вас есть сотни таблиц и большая обработка данных каждый минуты, это был бы ЦП и уничтожитель жесткого диска для управления версиями всей базы данных. Вот почему резервное копирование все еще, согласно мне, лучший способ управлять Вашими данными.
Я всегда проверяю свои дампы структуры базы данных в управлении исходным кодом. Полные дампы базы данных однако я обычно просто сжимаюсь и убираю для устройства хранения данных.
Программное обеспечение RedGate делает некоторые большие инструменты, которые помогут Вам присвоить версию своей базе данных. Обязательно попытайтесь иметь Ваш devs, создают их собственные изолированные локальные базы данных для работы dev, а не полагаются "dev сервер", который может или не может снизиться в некоторое время.
Моя команда присваивает версию нашей схеме базы данных как классам C# с остальной частью нашего кода. У нас есть программа C# собственной разработки (< 500 строк кода), который отражает классы и создает команды SQL, чтобы создать, отбросить и обновить базу данных. После создания базы данных мы выполняем sqlmetal для генерации отображения linq, которое тогда компилируется в другом проекте, который используется для генерации данных тестирования. Целые вещи работают действительно хорошо, потому что доступ к данным проверяется во время компиляции. Нам нравится он, потому что схема хранится в .cs файле, который легко отследить, выдерживают сравнение в trac/svn.
Я использовал RedGate SQL, Выдерживают сравнение Pro для синхронизации схемы с папкой сценария, тогда я передаю все свое обновление управления версиями. Это работает отлично.
У нас есть еженедельник sql дамп в подрывную деятельность repo. Это полностью автоматизировано, но это - ДЕЙСТВИТЕЛЬНО раскормленная задача.
Вы захотите ограничить количество изменений, потому что оно действительно жует дисковое пространство через некоторое время!
Я управление версиями создать сценарий, и я использую 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 не забывают тестировать Ваш код прежде, чем считать патч хорошим. Принцип "качество на риск покупателя"!
);
не забывают тестировать Ваш код прежде, чем считать патч хорошим. Принцип "качество на риск покупателя"!
Мы настаиваем на документах на получение изменения и сценарии определения основных данных. Они проверяются в CVS наряду с любым другим исходным кодом. МН / SQL (были, является магазин Oracle), также источник, которым управляют в CVS. Сценарии изменения повторяемы и могут быть переданы всем в команде. В основном просто потому что это - база данных, никогда нет оправдания не кодировать его и использовать систему управления исходным кодом для отслеживания изменений.
Мы поддерживаем сценарии DDL (и иногда DML), сгенерированные нашим ER Tool (PowerAMC).
У нас есть набор сценариев оболочки, которые переименовывают сценарии, начиная с номера в ветви ствола. Каждый скрипт фиксируется и помечается номером bugzilla.
Эти сценарии затем объединяются в ветвях выпуска вместе с кодом приложения.
У нас есть таблица с записями сценариев и их статусом. Каждый сценарий выполняется по порядку и записывается в этой таблице при каждой установке с помощью инструмента развертывания.
У Вашей проектной группы может быть DBA, кому каждый разработчик передал бы их создавать, изменяют, удаляют, вставляют/обновляют (для основных данных) sql операторы. DBAs выполнил бы те запросы, и при успешном создании необходимого обновления добавит те операторы к текстовому файлу или электронной таблице. Каждое дополнение может быть маркировано как точка сохранения. Упакуйте Вас, возвращаются назад к конкретной точке сохранения, просто сделайте отбрасывание все и выполните запросы uptil маркированная точка сохранения. Этот подход является просто мыслью..., немного точной настройки здесь работало бы на Вашу среду разработки.
Любой код интерфейса БД абсолютно должен войти в управление версиями (Хранимые процедуры, Функции, и т.д.).
Для структуры и данных, это - личный выбор. Я лично сохраняю чистый структурный шаблон своих баз данных вокруг, но не храню их в управлении версиями, из-за размера. Но хранение его в управлении версиями может быть очень выгодным, даже для того, чтобы просто иметь историю.
Большая проблема, часто пропускаемая, состоит в том, что для больших веб-систем, это требуется, чтобы иметь переходный период или подход к тестированию блока для создания новых выпусков. Это делает важным иметь и откат и механизм для поддержки и старая и новая схема в том же DB. Это требует подхода лесов (сделанный популистом Гибкими людьми DB). В этом сценарии отсутствие процесса в управлении исходным кодом DB может быть общим бедствием. Вам нужны старые сценарии схемы, новые сценарии схемы и ряд промежуточных сценариев, а также убирания, когда-то система находится полностью на новой версии (или откатывается).
Вместо того, чтобы иметь сценарии для воссоздания схемы с нуля то, что требуется, является основанным на состоянии подходом, где Вам нужны сценарии просто для перемещения DB в состояние, Вы требуете, оба передают и назад от версии до версии. Ваш DB становится рядом сценариев состояния, которые могут быть легко источником, которым управляют и теговый наряду с остальной частью источника.
К вашему сведению Это было также поднято несколько дней назад Dana... Сохраненная схема процедур/DB в управлении исходным кодом
RedGate великолепен, мы генерируем новые снимки при внесении изменений в базу данных (крошечный двоичный файл) и сохраняем этот файл в проектах как ресурс. Всякий раз, когда нам нужно обновить базу данных, мы используем инструментарий RedGate для обновления базы данных, а также можем создавать новые базы данных из пустых.
RedGate также делает моментальные снимки данных, хотя я лично с ними не работал, они такие же надежные.
Сами базы данных? Никакой
сценарии, которые создают их, включая статические данные вставляют, хранимые процедуры и т.п.; конечно. Они - текстовые файлы, они включены в проект и зарегистрированы и как все остальное.
, Конечно, в идеальном мире Ваш инструмент управления базой данных сделал бы это; но Вы просто должны дисциплинироваться об этом.
Я очень люблю миграцию Rails ActiveRecord. Он абстрагирует сценарий от DML до ruby, который может быть легко переведен в ваш исходный репозиторий.
Однако, немного поработав, вы можете сделать то же самое. Любые изменения DDL (ALTER TABLE и т. Д.) Могут быть сохранены в текстовых файлах. Сохраните систему нумерации (или отметку даты) для имен файлов и применяйте их последовательно.
Rails также имеет таблицу «version» в БД, которая отслеживает последнюю примененную миграцию. Вы можете сделать то же самое легко.
Выезд LiquiBase для руководящих изменений базы данных с помощью управления исходным кодом.
Вы никогда не должны просто входить в систему и начинать вводить команды "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
я уверен, что существует лучший способ сделать это, но он работал на меня до сих пор.
Да. Код является кодом. Мое эмпирическое правило - то, что мне нужно к быть в состоянии создать и развернуть приложение с нуля , не смотря на машину разработки или производства.
Лучшая практика, которую я видел, создает сценарий сборки, чтобы фрагментировать и восстановить Вашу базу данных по серверу подготовки. Каждому повторению дали папку для изменений базы данных, все изменения были заданы сценарием с "Отбрасыванием... Создайте". Таким образом, можно откатывать к более ранней версии в любое время путем указания на сборку на папку, к которой Вы хотите присвоить версию.
я полагаю, что это было сделано с NaNt/CruiseControl.
ДА, я думаю, что важно присвоить версию Вашей базе данных. Не данные, но схема наверняка.
В Ruby on Rails, это обрабатывается платформой с "миграциями". Любое время Вы изменяете дб, Вы делаете сценарий, который применяет изменения, и проверьте его в управлении исходным кодом.
Моему магазину понравилась та идея так, что мы добавили функциональность к нашей основанной на Java сборке сценарии оболочки использования и Муравей. Мы интегрировали процесс в нашу стандартную программу развертывания. Было бы довольно легко записать сценарии, чтобы сделать то же самое в других платформах, которые не поддерживают управление версиями DB out-of-the-box.
Новые проекты Базы данных в Visual Studio обеспечивают управление исходным кодом и сценарии изменения.
у Них есть хороший инструмент, который сравнивает базы данных и может генерировать сценарий, который преобразовывает схему одной в другой или обновляет данные в одном для соответствия другому.
схема дб "измельчена" для создания многих, многих маленьких .sql файлов, один на команду DDL, которая описывает DB.
<час> +tom
Дополнительная информация 30.11.2008
я использовал его в качестве разработчика в течение прошлого года и действительно как он. Это облегчает сравнивать мою работу dev с производством и генерировать сценарий для использования для выпуска. Я не знаю, являются ли это недостающие возможности, в которых DBAs нуждаются для проектов "типа предприятия".
, поскольку схема "измельчена" в sql файлы, управление исходным кодом хорошо работает.
Один глюк - то, что у Вас должно быть различное мышление при использовании проекта дб. Инструмент имеет "проект дб" в VS, который является просто sql плюс автоматически сгенерированная локальная база данных, которая имеет схему и некоторые другие администраторские данные - но ни одни из Ваших данных приложения, плюс Ваш локальный dev дб, что Вы используете для данных приложения dev работу. Вы редко знаете об автоматически сгенерированном дб, но необходимо знать там, таким образом, можно оставить его в покое:). Этот специальный дб является явно распознаваемым, потому что он имеет Гуид на свое имя,
, Проект DB VS делает хорошее задание интегрирующихся изменений дб, которые другие члены команды превратили в Ваш локальный дб проекта/связанный. но необходимо сделать дополнительный шаг, чтобы сравнить схему проекта с локальной dev схемой дб и применить модификации. Это имеет смысл, но это кажется неловким сначала.
Проекты дБ являются очень мощным инструментом. Они не только генерируют сценарии, но и могут сразу применить их. Обязательно не уничтожьте Ваш производственный дб с ним.;)
мне действительно нравятся проекты DB VS, и я ожидаю использовать этот инструмент для всех своих проектов дб продвижение.
+tom
Я сохраняю сценарии создания / обновления и сценарий, который генерирует выборочные данные.
Да, мы делаем это путем хранения нашего SQL как части нашей сборки - мы сохраняем DROP.sql, CREATE.sql, USERS.sql, VALUES.sql и управление версиями ими, таким образом, мы можем вернуться назад к любой теговой версии.
у Нас также есть задачи Ant, которые могут воссоздать дб при необходимости.
Плюс, SQL тогда отмечен наряду с Вашим исходным кодом, который идет с ним.
Самая успешная схема, которую я когда-либо использовал на проекте, объединила резервные копии и дифференциальные файлы SQL. В основном мы взяли бы резервное копирование нашего дб после каждого выпуска и сделали бы дамп SQL так, чтобы мы могли создать пустую схему с нуля, если бы мы должны были также. Тогда каждый раз, когда необходимо было внести изменение в DB, Вы добавите изменить документ на получение к sql каталогу при управлении версиями. Мы всегда снабжали бы префиксом порядковый номер или дату к имени файла, таким образом, первое изменение будет чем-то как 01_add_created_on_column.sql, и следующий сценарий был бы 02_added_customers_index. Наша машина CI проверила бы на них и выполнила бы их последовательно на новой копии дб, который был восстановлен от резервного копирования.
у Нас также были некоторые сценарии на месте, что devs мог использовать, чтобы повторно инициализировать их локальный дб к текущей версии с единственной командой.
Мы делаем управление исходным кодом все наш понижать качество созданных объектов. И только сохранить разработчиков честными (потому что можно создать объекты без них находиться в Управлении исходным кодом), наши dbas периодически ищут что-либо не в управлении исходным кодом и если они находят что-нибудь, они отбрасывают его, не спрашивая, ли это в порядке.