应该如何处理增量数据库模式的演变

How one should handle incremental database schema evolution

我有一个以数据库作为持久层的 Play 框架驱动的应用程序(为此我使用 Slick)。我启用了演进,生成了 1.sql 文件并成功将其投入生产。

客户请求需要修改数据库架构的新功能 - 即。添加新表、添加新列和更改现有列的可空性。

一旦更新了所有 Slick 的 Table 定义和相关代码,我再次生成架构并将其放置为 2.sql。进化被正确地请求为 运行 但是...生成的进化并不反映在 1.sql 状态之上的增量更新而是说明如何从头开始创建数据库模式(即 CREATE TABLE 包含所有列,包括新列而不是 ADD COLUMN 原因)。

是否有可能实现增量更新,以便我可以轻松地 运行 在生产中获取数据库从修订版 #1 到修订版 #2(SQL "diff" 之间#1 和 #2)还是我必须手动创建这些演变?

您只需要将差异放入进化脚本中。

例子

1.sql

CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255) 
);

2.sql

ALTER TABLE Persons ADD Email varchar(255);

现在,您的问题:

I generate schema once again and place it as 2.sql

你重新生成了它所以你的文件看起来像

1.sql

CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255) 
);

2.sql

CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255) 
);
ALTER TABLE Persons ADD Email varchar(255);

您只需要对 2.sql 进行增量更改,就像我的示例一样。

您必须在 v1 之后手动创建这些演变。

对于我们的产品,当产品处于发货前开发阶段时,我们将 "generate evolutions" 保持打开状态。一旦 v1 准备好部署,我们将关闭自动进化生成并开始手动进化。

虽然这可能感觉不太理想,但作为一个团队,我们感到更自在table 知道人类正在编码和审查 DDL(有时是 DML)SQL 演化语句,而不是一个自动脚本决定也许 table 应该被删除并重新创建。在某些产品中,我们有数百个 evos,跨越多年不断改进和适应。该系统运行良好。