postgresql 有什么理由不使用Flyway SQL脚本将数据从一个表移动到另一个表?

lnxxn5zx  于 2023-06-22  发布在  PostgreSQL
关注(0)|答案(2)|浏览(188)

我的项目中有两个表:

旧表

| 冷|B柱|C柱|
| - -----|- -----|- -----|
| X线|y| z|
| 一种|B| c型|

新表(架构略有不同)

| 冷|B柱|另一个col|
| - -----|- -----|- -----|
| X线|y|布拉|
正如您所看到的,旧表包含一些新表没有的数据。这是因为代码最近才开始填充新表。因此,我需要将数据从遗留表移动到新表中,在新表中不存在旧记录的id。
我的应用程序是一个简单的Sping Boot KotlinAPI,使用Flyway使用Postgres DB技术。
我的问题是:处理此数据迁移的额外Flyway脚本是否会导致任何技术问题?我见过Flyway SQL脚本用于构造/更改模式,但还没有看到它们实际应用于将数据从一个表移动到另一个表。有什么理由不这样做吗?

0dxa2lsx

0dxa2lsx1#

使用Flyway移动数据被认为是一种合适的做法。事实上,Flyway非常适合此目的,只要脚本经过精心制作,并且在原始问题的范围之外没有其他因素会阻止数据移动。
与我过去遇到的复杂数据操作相比,移动数据而不进行任何进一步的转换似乎相对简单。
Flyway脚本具有广泛的适用性,包括数据填充、数据删除、数据更新和模式操作等任务。这些操作可能涉及添加或删除列、更改数据类型或创建和删除表。通常,这些任务是相互关联的,例如添加新列,需要在该列中填充数据,这可能涉及查询现有数据。

oxcyiej7

oxcyiej72#

虽然现有的答案谈论技术可行性,但也许从操作Angular 也会有用。
根据我的经验,最有效的方法是确保每个表数据都有一个单一的更改源,即一个进程/实体负责任何数据更改。特别是将批处理/部署时过程与手动“干预”混合在一起,这是我不惜一切代价试图避免的争论焦点。
实际含义是数据库迁移应该只处理:

  • 架构的结构更改
  • 对字典表中数据的更改,未向其提供管理界面

如果要我决定Flyway脚本是否适合给定的场景,我会问自己这个场景是否是上述之一。
现在回到眼前的场景你提到
这是因为代码最近才开始填充新表。
这意味着这实际上是一个正在被应用程序主动修改的操作表。这将告诉我:(1)该场景绝对不属于我提到的类别之一,(2)迁移数据和当前数据之间冲突的可能性如此之大,以至于我永远不会相信自动化进程在没有任何监督的情况下正确处理迁移。特别是如果该脚本作为部署过程的一部分运行,而部署过程可能是由其他人随意运行的。
在这个答案中,我当然对你的组织如何运行做了一些假设,所以请持保留态度。您的里程数可能会有所不同。

相关问题