这是一个创建于 1800 天前的主题，其中的信息可能已经有所发展或是发生改变。
请问大佬流行的解决方案有哪些啊？
 |
1
qmzhixu 2020-01-07 10:49:38 +08:00
navicat 的结构同步工具
|
 |
2
SjwNo1 2020-01-07 10:57:44 +08:00
写个 sql 文件？
|
 |
3
fanpei0121 OP 比如 A 开发的时候改变了表结构，同事 B 也改变了另一张表的结构。最终数据库怎么把 2 张表的结构统一，有没有解决方法
|
 |
4
hsk9044 2020-01-07 11:01:23 +08:00
既然是多人开发, 如果是开发相同功能, 数据库不应该是连同一个吗? 如果是功能不同, 那参考 1#的工具
|
|
5
fanpei0121 OP @hsk9044 但是本地开发，开发人员都是安装的本地数据库，你的意思是都用一个数据库？
|
 |
6
murmur 2020-01-07 11:08:23 +08:00
我们是数据库由专人负责修改
|
 |
7
VictorJing94 2020-01-07 11:09:17 +08:00
所以你们数据库也是独立设计嘛[狗头],不都是大佬先开会,统一架构,还有 ER 图,然后确定数据库后再分模块分功能去开发嘛....
|
|
8
fanpei0121 OP @VictorJing94 额。。。。小公司都是开发人员自己建表。。<(..)>
|
 |
9
sxw11 2020-01-07 11:13:07 +08:00  1
不应该是共用一个开发或者测试数据库吗，人多了本地库很麻烦，非要那样就每个人提交代码的时候把数据库变动的 sql 脚本也提交了
|
 |
10
SuperMari0 2020-01-07 11:13:34 +08:00
统一连一个开发用的库就好了
|
 |
11
optional 2020-01-07 11:13:37 +08:00 1
migration，
|
 |
12
helionzzz 2020-01-07 11:15:45 +08:00
就算初始数据有出入，所有人数据表结构不应该是一样的么。如果期间发现有要改变的，不应该通知所有人一起改么。。你们开发中间团队完全不交流的？
|
 |
13
luckyrayyy 2020-01-07 11:18:44 +08:00
肯定使用公共开发库啊，每人一个本地库也太麻烦了。
|
|
14
fanpei0121 OP @luckyrayyy 是的，决定都连测试服数据库了
|
 |
15
evlos 2020-01-07 11:20:11 +08:00 via Android
Migration
|
 |
16
di94sh 2020-01-07 11:23:33 +08:00 via iPhone
如果是 django orm 或者 sqlalchemy 这种 migrate 做的比较完善，migrate 文件 有单独的文件夹存放. merge 了代码运行迁移脚步就好了。如果用的数据库工具没有 migrate 功能，可以用 sqlalchemy 的迁移工具 alembic 需要自己手写迁移脚步，其实就是 DDL
|
 |
17
opengps 2020-01-07 11:24:06 +08:00
共享连接同一个数据库
|
 |
18
Orenoid 2020-01-07 11:37:19 +08:00
把数据库结构纳入版本管理
|
 |
19
oatw 2020-01-07 11:39:12 +08:00 via iPhone 2
看到这个问题，再次庆幸自己选择 Rails 作为后端开发的主要工具。
|
 |
20
wangkun025 2020-01-07 11:40:51 +08:00
rails 用 migration。
但偶尔也会出问题。 |
 |
21
adrianXu 2020-01-07 11:59:56 +08:00
java 有 flyway liquibase 这种工具
|
 |
22
soli 2020-01-07 12:00:11 +08:00
建表 SQL 写在 sql 文件中。
所有 sql 文件作为源码文件提交版本库。 剩下的就和代码一样的流程了。 |
 |
23
BALDOOR 2020-01-07 12:02:44 +08:00 via Android
我们用文件把新增 /修改的 sql 记录下来
运行时出错时，通过分析 sql 报错信息 再去查找文件去修正数据库 目前运行情况良好，感觉还挺 nice 的 |
 |
24
fx 2020-01-07 12:34:47 +08:00
Migration
|
|
25
fx 2020-01-07 12:35:11 +08:00
|
 |
26
af463419014 2020-01-07 12:40:05 +08:00
建议规范一下开发流程
开发前先写设计文档,包括技术方案和表结构设计等,然后大家评审,评审完成后再进行代码开发 一般白天写文档,晚上花 1-2 小时完成评审,也就多出一天的研发周期,能为将来避免很多不必要的麻烦 |
 |
27
lygmqkl 2020-01-07 13:36:35 +08:00
migrate
|
 |
28
phpcxy 2020-01-07 13:46:53 +08:00
写数据库迁移文件
|
 |
29
linxl 2020-01-07 13:59:12 +08:00
肯定得连接同一个数据库, 其它的无论什么方案都不如同一个数据库来得方便, 而且只是开发阶段
|
 |
30
minigo 2020-01-07 14:02:20 +08:00
用 orm 的没这个问题，用纯 sql 的链同一个库吧。不然开发完你会后悔的
|
|
31
VictorJing94 2020-01-07 15:40:06 +08:00
|
 |
32
agagega 2020-01-07 16:02:12 +08:00 via iPhone
原来这年头还有后端框架不用 Migration 的吗😂
|
 |
33
nanwangnongfu 2020-01-07 17:34:30 +08:00
总结一下
1，链接同一个测试库 2，使用 migratiion，更新代码，执行 migration 命令 3，更改写入 sql 文件，更新代码，手动执行 |
 |
34
dcalsky 2020-01-07 17:56:45 +08:00
这个问题之前研究过。
## Migration Code first 的解决方案（有编程语言依赖）：依赖你 ORM 提供的 migration 工具，如楼上提到的 Django，sqlalchemy 等。 Basebase first 解决方案（无编程语言依赖）：sqitch 或者 flyway，都是工具，别管用什么语言开发的。 ## 多人协作 肯定要用 git 管理这些 migrations，然后建议开一个数据库的线上 beta 版本，等稳定了再 migrate 到 prod 版本上。 流程一般是：开发者 A 改动了 schema，生成 migrations 并 push 到仓库 -> 开发者 B pull 这些 migrations，然后 migrate 到本地的数据库。至于你们什么时候想 push 到 beta，以及 CI/CD 的其他事情，别的贴再讨论吧。 |
 |
35
Leigg 2020-01-07 20:08:44 +08:00 via Android
不要瞎搞，这哪有完美方案，到时候一堆问题，公司网装一个公共的 mysql 才是办法
|
 |
36
zhuzhibin 2020-01-08 02:07:42 +08:00 via iPhone
都说 migration,那我请教下随着项目变大业务变更大，导致迁移文件越来越多，要怎么维护比较好？
|
Select Language