【问题标题】:Postgres Dump Alter QueriesPostgres 转储更改查询
【发布时间】:2015-10-21 21:48:13
【问题描述】:

我对 postgres 很陌生,并且对来自 MySQL 的 SQL 生疏了。

我想要实现的是使用现有数据库结构生成转储文件,然后我可以使用它来将更改部署到可能已经包含或不包含该数据库的环境。

我认为这意味着转储可能包含以下内容:

  • 空的条件CREATE 查询所有表(条件如'如果不存在'...)
  • 有条件的ALTER 查询所有字段
  • 有条件的ALTER 查询所有约束和键(主键和其他键)

我现在对转储数据不感兴趣。

显然,这需要能够创建不存在的数据库结构,但主要是我对运行已经存在数据库但结构不是最新的脚本感兴趣。这个想法是,它将在不存在的地方添加相关字段/键/等,从而使数据库保持最新。

我知道部署是软件工程的常规部分,所以我假设有:

  • 一种简单的方法,或者
  • 没有这样做的一个很好的理由。

请提供以上其中一项作为答案。 :)

【问题讨论】:

  • 您需要将此集成到您的开发周期中,并且只需通过置于版本控制之下的脚本对数据库进行每一次更改。 Liquibase 是一个很好的工具来管理这样的架构迁移。

标签: database postgresql


【解决方案1】:

通常,您首先会自动执行更改,然后在部署到每个实例时应用相同的自动化。 Liquibase 等工具可以帮助您。

很多没有按照你描述的那样完成:

  • 有些事情,如列数据类型更改,非常很难以这种方式处理。你 ALTER 从 text 到 integer USING (NULLIF(trim(column)::integer, '')) 的列删除空格并将 '' 转换为 NULL。转储怎么会知道这样做?

  • 有时,更改看似没有净效果,但实际上非常重要。 DROP TABLE mytable; CREATE TABLE mytable(...) 与 ALTER TABLE mytable ... 非常不同,因为它破坏了数据,但是当您只查看数据库状态时,您看不到这一点。

  • 有时当您查看状态 A 和 B 时,很难判断从 A 到 B 实际需要哪些转换。可能有很多方法可以做到这一点,也可能是不可能的无需经过一些不明显的中间状态。

尝试同步数据定义是一种非常笨拙的方法,而且很可能会破坏。

使用可以根据已知的起始架构版本和明确定义的转换(迁移)集以受控方式进行一系列更改的架构版本控制工具。一些框架内置了这样的功能。对于其他人,您可以使用 Liquibase 等工具。

【讨论】:

  • 我典型的 diff 无法检测到的情况示例:alter table foo rename to bar; diff 工具唯一可以(并且将会)做的事情就是生成一个 drop table foo 和一个 create table bar
猜你喜欢
  • 2019-03-27
  • 2021-01-01
  • 2016-10-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-20
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多