请建议一种更好的方法来组织开发数据库

时间:2010-01-06 12:59:54

标签: project-management

我目前正在开发一个Web项目,我们都连接到一个开发数据库。

与其他集中式系统一样,这个数据库最终会成为单点故障。

如果其中一个开发人员不小心将一些脏数据转储到数据库中,那么所有其他开发人员都会受此影响。

所以我想也许我们应该做点什么,比如说,我们每个人都制作原始数据库的副本,然后我们设置我们的Web应用程序来连接到本地数据库。

在我的案例中,团队的核心成员是五个开发人员,一个测试人员(主要是黑盒测试)。开发过程继续这样:每个开发人员负责一个子功能并在他自己的分支上工作,然后我们将他的分支合并到测试应用程序测试应用程序的主干上。

请给我一些建议。

6 个答案:

答案 0 :(得分:2)

让每个人从他们自己独立的数据库副本开发的问题是他们不会接受其他开发人员的更改。

例如,如果有人向数据库表添加了一列,则其他开发人员将不会意识到这一点。其他人也可能无意中添加了相同的列。

并且,如果某人以需要更改应用程序代码的方式更改存储过程(例如,添加输入参数),则其他开发人员将不知道这一点。如果他们从源代码管理中获取更新代码,则无法在其本地数据库副本上运行。

我同意拥有越来越混乱的开发数据库是一个问题。但我不确定从数据库的多个副本开发是否会减少开发问题的数量。

我认为可能无法使用的一种替代方法是定期将生产数据库复制到开发中。通常,这只能在新版本之后发生,该版本在生产数据库模式中需要进行任何更改。但是你必须有一个生产数据库才能做到这一点。

答案 1 :(得分:1)

对我的公司非常有效的解决方案是为每个开发人员在虚拟机中运行数据库。

我们为每个支持的数据库(oracle,db2,mssql,mysql)设置了一个虚拟机。现在,每个开发人员都可以在本地复制和运行虚拟机,而无需安装它。

答案 2 :(得分:1)

我发现花时间建立一个系统,每个开发人员都有自己的数据库,每次运行单元测试时都会刷新,重建并填充测试数据。通过这种方式,你永远不会处于彼此的方式。当然,持续集成和测试服务器也应该有自己的数据库。

只要DDL和测试数据处于版本控制中,每个人都在对同一个数据库进行操作。另一个优点是,如果我正在处理需要更改数据库的功能,则每个人都会获得该更改所需的代码和DDL +测试数据。

在Java领域,DbUnit,在我们的例子中与Hibernate Maven插件一起,对此非常有帮助。当然,简单的自制程序解决方案可能会很好。

答案 3 :(得分:0)

在我的项目中,开发数据库始终位于开发人员本地计算机上。我们使用SQL Server Developer Edition或SQL Server Express。我们保留了一个SQL脚本,用于在源代码库中创建已签入的DB。任何需要重新创建本地数据库的人都可以使用它。一个团队成员负责维护SQL脚本,并且首先对他进行任何数据库更改(通常为SQL脚本)。他从SCM获取最新版本的脚本,更新其本地副本并生成更新的创建脚本,该脚本替换SCM中的脚本。同时将附带的代码更改检入SCM,以便代码和数据库同步。其他人都同步到这个版本。

这使人们可以自由地并行工作,并根据需要进行架构更改,包括可能被删除的实验性更改。我们还使用本地数据库作为虚拟数据的来源,用于本地测试Web应用程序 - 而不是单元测试,我们通常会为此模拟数据库,但需要集成和UI测试。保持本地数据库的独立性允许每个开发人员根据需要进行测试,而无需与其他人协调。

我还应该提一下,一旦协调器的本地数据库处于官方签入版本,我们就会使用Red Gate's SQL Compare来传播更改。这是删除和重新创建数据库的替代方法,可以更好地保留现有数据。根据数据库的变化,这可能是一个微不足道的或有些复杂的操作。我们总是使用它来更新质量保证/测试和生产数据库,除非这些更改非常简单,可以手工制作(没有错误)。

答案 4 :(得分:0)

个人本地SQLite数据库怎么样?许多Rails开发人员对该解决方案感到满意。

答案 5 :(得分:0)

我们使用与其他人在此描述的相同的基本过程,并进行了一些重大更改。每个开发人员通常都有自己的数据库实例,我们使用更改脚本进行管理。以下是详细信息:

  1. 我们有一个基础数据库脚本来创建初始数据库。这包括在db中创建一个表,用于跟踪db的模式版本。
  2. 所有SP,视图和函数都编写到单个文件中。
  3. 如果需要进行架构更改,可以编写执行该更改的脚本。它必须检查模式版本表以确保db是正确的版本以应用此模式更改。像Red-Gate工具这样的东西有助于编写这些脚本,但它们并不是必需的。
  4. 我们编写了一个小程序,可以针对数据库自动运行所有这些脚本。它将检查数据库的当前模式版本,并仅运行新的模式更改脚本。它将始终运行SP,视图等脚本的所有
  5. 由于模式更改脚本必须在文件名中编码其版本号,因此在两个开发人员都创建相同的版本脚本时,可能会出现冲突。有时您可能会有一个处于不一致状态的数据库,并且自动化进程将失败。但总的来说,它对我们来说非常有效。