Question

看到这个：Need a better way to manage database schema changes

可以为MySQL做些什么？

现在，如果有架构更改，我必须稍微考虑一下，查看差异，手动应用更改，然后运行数据迁移/转换脚本。

很想知道是否有可以减轻痛苦的方法/工具。

Answer 1

为什么不在更新脚本中累积对开发模式的更改，只需在下一个版本上运行脚本。

真的有不同的架构比较工具，但是，在我看来，它们应该仅用于检查更新脚本是否正确，而不是生成脚本。

在发布时，您应该将生成新架构的脚本和更新脚本作为空提交给版本控制系统。

假设这是您的架构：

-- 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

我想看看一个比较工具，它可以让你做得更简单。

Answer 2

我认为一种好方法是对数据库进行更改，就像对代码进行更改一样。让它们处于源代码管理中，并使部署良好且可重复。

我对这种事情的理念就像DevOpsWire上的这种模式：https://web.archive.org/web/20111025093215/http://devopswire.com/patterns/database-changes-as-code

工具方面，看看像DB-Deploy和Liquibase这样的东西。

Answer 3

相同的方法定义Need a better way to manage database schema changes Compare two MySQL databases可以完美地运作。

您还可以查看比较相关帖子here。

更多的是，维护您在暂存或预部署时可能会做的更改脚本并在转移到生产时一次执行它们总是很好。

无痛数据库架构更改

3 个答案: