看到这个:Need a better way to manage database schema changes
有什么可以为 MySQL 做的吗?
现在,如果架构发生变化,我必须暂时关闭产品,查看差异,手动应用更改,然后运行数据迁移/转换脚本。
很想知道是否有可以减轻疼痛的方法/工具。
最佳答案
为什么不在更新脚本中累积对开发架构的更改,并在下一个版本上运行脚本。
确实有不同的模式比较工具,但在我看来,它们应该只用于检查更新脚本是否正确,而不是用于生成脚本。
并且在发布时,您应该将生成新模式的脚本和更新脚本作为空脚本提交给版本控制系统。
假设这是您的架构:
-- 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;
提交 2
发布
-- 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
提交 3
我想看看一个比较工具,它可以让您更轻松地完成这项工作。
关于mysql - 无痛数据库架构更改,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8542570/