这是一个创建于 1859 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目是按迭代（每周）走的，目前每个迭代都会有一个存放本迭代产出的 sql 的文件。然后平时这个文件在迭代内就会被无限次重复部署（测试用）。。。这样很容易出问题，请问有改良的方法吗？谢谢
 | 1 helloworld2010 2020-09-21 17:15:03 +08:00 文件名加个版本号（日期，序号等） |
 | 2 NotreDame OP @helloworld2010 之前就是“迭代名+日期”，发现文件堆积的很快，就改成一个迭代只有一个 sql 文件了，但是很不利于重复部署。 |
| 3 helloworld2010 2020-09-21 17:21:03 +08:00 @NotreDame 定期删掉旧 sql 文件呢？再不然按子功能分目录保存。 |
 | 4 dswyzx 2020-09-21 17:28:33 +08:00 sql 语句考虑重复执行. 写法上的强制要求 有一个思路是:git 管理,然后定期抽取区间时间历史的 sql 语句进行批量执行 |
 | 5 l00t 2020-09-21 17:50:37 +08:00 不明白在说什么…… 重复部署会有什么问题吗？能出什么问题？ |
 | 6 MarioLuo 2020-09-21 18:11:15 +08:00 via Android  1 Java 项目可以使用 Liquibase 进行 sql 管理自动化，也可以手工管理 1.集中存储 sql 变更: git, wiki 2.开发测试如果环境分离那么提测时由测试执行 sql 变更 |
 | 7 doufum 2020-09-21 18:12:08 +08:00 maven flyway plugin，配合版本管理的 tag |
 | 8 imydou 2020-09-21 18:13:10 +08:00 via iPhone laravel migration |
 | 9 march13th 2020-09-21 19:41:25 +08:00 可以学习下 python django 中的模型管理 migration |
 | 11 yazoox 2020-09-22 10:11:05 +08:00 看到这个帖子，想起了自己的青葱岁月。\ 很多很多年前，入职一家公司，负责修复一个 SQL 的语句的 bug 。\ 打开文件一看，那条（没错，是一条） SQL 语句，居然有 2000 行...... 然后，在我离开的时候，已经 3000+行了\ ;-) |
 | 12 justgodlike1993 2020-09-22 11:57:25 +08:00 @yazoox 看懂这 SQL 语句花了多久时间 |
 | 13 zhangysh1995 2020-11-17 20:20:05 +08:00 要不要试试科研产物那些自动抽取 sql 的工具 （手动滑稽 https://csnagy.github.io/research/pdfs/2017/Nagy-SCAM2017.pdf |
Select Language