若团队用 GitHub 做协同开发和版本控制，数据库应该如何共享？

参考 rails db migration,
就算不用rails,也可以单独使用 rails的migration模块

架设一个公用的数据库服务器=。= 我太蛋疼了。

@fx 他说的应该是数据库数据吧，数据库结构的话不就是一个sql文件的事吗

一般用migration工具来保证数据库的完整性，然后根据不同的构建工具来配合。
如果是java，maven的话用flyway。

我觉得一个比较简单但是挺low的办法就是如果是mysql的话可以参考用mysqldump，然后交给对方去还原。

弄一个可远程连接的数据库，大家连同一个，就 mysql 或者 sql server 来说都可以，网上也有相应的服务，价格很低，其它数据库没接触过。

不要共享数据库，共享数据库结构就可以了。

共享数据库结构的话，用 migration 也罢，用 SQL 也罢，自己写个机制也罢，都不会很麻烦。

用 docker 吧

liquibase

用sqlite3直接一起commit push

我比较low地用了远程数据库，感觉还不错，安全性还需考虑。

我们的做法是：

* 团队里的成员都用 phpMyAdmin 管理各自开发环境里的数据库
* 每次 phpMyAdmin 里确定要改任何东西的话（大的更改之前肯定是有会议记录的），把实际执行了的那句 SQL 发到内部的协作系统里（比如论坛，Basecamp 或者 Quip 之类的系统），并且加上一些文字说明这个修改的目的是什么
* git commit 时也同时要提到需要进行 SQL 操作
* git repo 包括一个当前最新的原始数据库的 SQL 定义

同时因为代码全程都用 Sentry 监控，所以如果 git pull 之后发现是因为表结构不一致导致的问题的话，马上就收到邮件了。

更改的sql也可以通过类似update.sql放到git里管理

基本原则就是库数据不能进入版本控制，只共享结构，也就是说明性文档、数据库生成代码等等。
中心化的一个共享测试数据库在有的阶段并不适用，团队成员调试bug时的的误操作可能会污染这个数据库，影响测试的正确性和可重复性。所以必须要有分布式的方案，每个成员跑隔离的数据库。
我曾经在一个项目里用过脚本自动按规则生成随机测试数据，在测试的setup里创建填充数据库，teardown的时候销毁，这样需要共享的数据量最小，能保证可重复性，而且随机数据的测试覆盖率也要高得多。

数据库表 table_name_user 用于个人开发 table_name_demo 用于大家协作， table_name_online 线上版本

@gracece 速度不会变慢吗？
@Livid @akfish 非常感谢。

@fim8 因为是在同一个局域网里面，所以速度没什么影响。

SQLite 可以吗

用过Python和node.js来写过两个相似的web站点项目，第一个数据库(mysql)是通过使用mysqldump的方法导出来push到repo上，第二个是数据库(mongodb)通过放在一个共同的服务器上，这样修改代码就不需要考虑数据的重复复制