这是一个创建于 1535 天前的主题，其中的信息可能已经有所发展或是发生改变。
项目是按迭代（每周）走的，目前每个迭代都会有一个存放本迭代产出的 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