無痛數據庫架構更改

Question

看到這個： 需要一種更好的方法來管理數據庫架構更改

有什么可以為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

相同的方法定義了需要更好的方法來管理數據庫模式更改 比較兩個MySQL數據庫將完美地工作。

您還可以在此處查看比較相關的帖子。

更重要的是，維護在暫存或預部署時可能會執行的更改腳本並在遷移到生產時一次執行它們總是很好的。