1
fx 2014 年 7 月 11 日
参考 rails db migration,
就算不用rails,也可以单独使用 rails的migration模块 |
2
hging 2014 年 7 月 11 日
架设一个公用的数据库服务器=。= 我太蛋疼了。
|
3
datou552211 2014 年 7 月 11 日
@fx 他说的应该是数据库数据吧,数据库结构的话不就是一个sql文件的事吗
|
4
JoshuaJin 2014 年 7 月 11 日
一般用migration工具来保证数据库的完整性,然后根据不同的构建工具来配合。
如果是java,maven的话用flyway。 |
5
jinnietsai 2014 年 7 月 11 日
我觉得一个比较简单但是挺low的办法就是如果是mysql的话可以参考用mysqldump,然后交给对方去还原。
|
6
abelyao 2014 年 7 月 11 日
弄一个可远程连接的数据库,大家连同一个,就 mysql 或者 sql server 来说都可以,网上也有相应的服务,价格很低,其它数据库没接触过。
|
7
dorentus 2014 年 7 月 11 日
不要共享数据库,共享数据库结构就可以了。
共享数据库结构的话,用 migration 也罢,用 SQL 也罢,自己写个机制也罢,都不会很麻烦。 |
8
jamesxu 2014 年 7 月 11 日
用 docker 吧
|
9
sunus 2014 年 7 月 11 日
liquibase
|
10
ericls 2014 年 7 月 11 日 via Android
用sqlite3直接一起commit push
|
11
gracece 2014 年 7 月 11 日
我比较low地用了远程数据库,感觉还不错,安全性还需考虑。
|
12
Livid MOD PRO 我们的做法是:
* 团队里的成员都用 phpMyAdmin 管理各自开发环境里的数据库 * 每次 phpMyAdmin 里确定要改任何东西的话(大的更改之前肯定是有会议记录的),把实际执行了的那句 SQL 发到内部的协作系统里(比如论坛,Basecamp 或者 Quip 之类的系统),并且加上一些文字说明这个修改的目的是什么 * git commit 时也同时要提到需要进行 SQL 操作 * git repo 包括一个当前最新的原始数据库的 SQL 定义 同时因为代码全程都用 Sentry 监控,所以如果 git pull 之后发现是因为表结构不一致导致的问题的话,马上就收到邮件了。 |
13
orcx 2014 年 7 月 11 日
更改的sql也可以通过类似update.sql放到git里管理
|
14
akfish 2014 年 7 月 11 日 基本原则就是库数据不能进入版本控制,只共享结构,也就是说明性文档、数据库生成代码等等。
中心化的一个共享测试数据库在有的阶段并不适用,团队成员调试bug时的的误操作可能会污染这个数据库,影响测试的正确性和可重复性。所以必须要有分布式的方案,每个成员跑隔离的数据库。 我曾经在一个项目里用过脚本自动按规则生成随机测试数据,在测试的setup里创建填充数据库,teardown的时候销毁,这样需要共享的数据量最小,能保证可重复性,而且随机数据的测试覆盖率也要高得多。 |
15
huoxiaochai 2014 年 7 月 12 日
数据库表 table_name_user 用于个人开发 table_name_demo 用于大家协作, table_name_online 线上版本
|
18
suprod 2014 年 7 月 13 日 via iPhone
SQLite 可以吗
|
19
laoisaudi 2014 年 9 月 2 日
用过Python和node.js来写过两个相似的web站点项目,第一个数据库(mysql)是通过使用mysqldump的方法导出来push到repo上,第二个是数据库(mongodb)通过放在一个共同的服务器上,这样修改代码就不需要考虑数据的重复复制
|