在源代码管理中管理我的数据库

这是正确的,您应该签入脚本,而不是数据库文件本身。

我不喜欢从测试数据构建数据,除非数据本身会模拟生产数据的大小(或者,在新数据库的情况下,是预期的)。为什么?因为在有100条记录的表上编写代码并不能告诉您当您有10000000条记录时,它是否会及时运行。我有太多的错误的设计选择来自那些认为小数据集可以用于开发的人。

在这里,我们不允许开发人员在他们的盒子上有一个单独的数据库(这通常限制了数据库不作为附加到SAN的服务器的virture所能达到的大小),相反,他们必须与从prod定期刷新(然后运行所有新开发人员脚本)的开发人员数据库一起工作,以保持数据的正确大小。我认为您的dev-datbase环境尽可能地与prod匹配是很重要的,包括设备配置、数据库大小等。没有什么比花很长时间开发在prod上根本不起作用的东西更让人沮丧的了,也没有什么比花很长时间开发在prod上更让人沮丧的了,因为它会使系统速度过慢。

现在从我的肥皂盒上跳下来。

签入脚本是个好主意,因为源代码控制最适合处理文本文件,而不是二进制文件。脚本文件中的差异可以作为与数据库更改相关的其余代码更改的一部分轻松查看。除了检入数据库脚本之外,我们还检入数据库模式快照。此数据库架构快照允许我们验证生产中的架构是否与产品给定版本的预期架构匹配。此外,数据库模式快照是使用纯文本编辑器搜索列和表的简便方法。

我使用Dataconstructor,但因为我写了它而有偏见。

尝试SQL审查员: How to keep your database under version control

你可以使用像这样的工具 Liquibase 管理数据库脚本。它实际上是一个数据库升级框架,因此它将跟踪已经执行的步骤,因此当您想要升级生产时,例如,它只执行新的步骤。