почему бы не накапливать изменения в схеме разработки в скрипте обновления и просто запустить скрипт в следующем выпуске.
Есть действительно разные инструменты сравнения схем, но, на мой взгляд, они должны бытьиспользуется только для проверки правильности сценария обновления, а не для создания сценария.
И при выпуске следует зафиксировать сценарий, который генерирует новую схему, и сценарий обновления как пустой для системы контроля версий.
Предположим, вот ваша схема:
-- schema.sql
CREATE TABLE t1 (
`t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
`t_data` VARCHAR(45) NOT NULL,
PRIMARY KEY (`t_id`)
) ENGINE = InnoDB COLLATE utf8_feneral_ci;
Фиксация 1
Теперь у вас в рабочей таблице много данных с большим количеством дубликатов, и выхотел бы сделать некоторую нормализацию:
- поместить отдельные данные в отдельную таблицу
- использовать ссылку в таблице t1:
Сценарии:
-- updates.sql
CREATE TABLE t2 (
`d_hash` CHAR(32) NOT NULL COLLATE ascii_general_ci,
`t_data` VARCHAR(45) NOT NULL,
PRIMARY KEY (`d_hash`)
) ENGINE = InnoDB COLLATE utf8_general_ci;
ALTER TABLE t1
ADD COLUMN `d_hash` CHAR(32)COLLATE ascii_general_ci AFTER `t_data`;
UPDATE t1 SET d_hash = MD5(UPPER(t_data));
INSERT IGNORE INTO t2 (t_data, d_hash)
SELECT t_data, d_hash
FROM t1;
ALTER TABLE t1 DROP COLUMN `t_data`,
MODIFY COLUMN `d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
ADD CONSTRAINT `FK_d_hash` FOREIGN KEY `FK_d_hash` (`d_hash`)
REFERENCES `t2` (`d_hash`) ON DELETE CASCADE ON UPDATE CASCADE;
Commit 2
Release
-- schema.sql
CREATE TABLE t1 (
`t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
`d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
PRIMARY KEY (`t_id`),
KEY `FK_d_hash` (`d_hash`),
CONSTRAINT `FK_d_hash` FOREIGN KEY (`d_hash`)
REFERENCES `t2` (`d_hash`)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB COLLATE utf8_general_ci;
-- updates.sql
-- Empty
Commit 3
Я хотел бы взглянуть на инструмент сравнения, который будетпозволит вам сделать это намного проще.