在数据库网站上的小团队中进行协作时，您采取了哪些流程？
我们在网站文件上工作没有任何问题，因为它们处于版本控制之下，因此我们的任何开发人员都可以在网站的这个方面从任何位置工作。
但是，当需要进行数据库更改时（直接作为开发的一部分或通过在CMS中进行内容更改而隐式），显然不同的开发人员很难合并这些数据库更改。
到目前为止，我们的方法仅限于以下内容：
我很想知道你是否有更好的建议。
我们主要使用MySQL数据库，目前不跟踪这些数据库的修订。上面讨论的问题主要涉及Drupal和Wordpress站点，其中大量的“开发”与CMS中数据库的更改一起执行。
答案 0 :(得分：2)
您将所有数据库更改放在SQL脚本中。将某种序列号放入每个脚本的文件名中，以便了解它们必须运行的顺序。然后将这些脚本签入源控制系统。现在，您可以将可重复的步骤应用于测试和生产数据库。
答案 1 :(得分：2)
虽然您可以将所有DDL放入VC中，但如果您尝试管理大量ALTER语句，这会很快变得非常混乱。
强制所有开发人员使用相同的源数据库也不是一种非常有效的方法。
我使用的解决方案是为每个数据库实体维护一个文件，指定如何创建实体（主要是因为可以使用diff实用程序查看更改），然后通过将发布版本与当前版本进行比较来手动创建ALTER语句 - 是的，它是相当劳动密集型的，但是我找到解决问题的唯一方法。
我有一个计划自动生成ALTER语句 - 它应该相对简单 - 确实是一个快速谷歌找到this article和this one。由于这样做的努力比我正在进行的项目的模式更改频率要大得多，所以从来没有完成自己实现的工作。
答案 2 :(得分：1)
在我工作的地方，每个开发人员（实际上，每个开发虚拟机）都有自己的数据库（或者更确切地说，在共享的Oracle实例上有自己的架构）。我们的工作流程以完全重建为基础。我们没有任何能力来修改现有的数据库 - 我们只有一个核选择就是吹走整个架构并从头开始构建。
我们有一个'drop everything'脚本，它使用系统表上的查询来识别模式中的每个对象，构造一堆SQL来删除它们并运行它。然后我们有一堆充满CREATE TABLE语句的DDL文件，然后我们有一堆XML文件，其中包含系统的初始数据，这些数据由加载工具加载。所有这些都被检入源代码控制。当开发人员从源代码管理进行更新时，如果他们看到传入的数据库更改（DDL或数据），则会运行主构建脚本，该脚本运行它们以便从头开始创建新数据库。
好的一点是，这会让生活变得简单。我们永远不需要担心差异，增量，ALTER TABLE，可逆性等，只需要简单的DDL和数据。我们永远不必担心保留数据库的状态或保持清洁 - 只需按一下按钮就可以恢复到干净的状态。这样做的另一个重要特征是，它使建立一个新平台变得微不足道 - 这意味着当我们添加更多开发机器，或者需要建立一个验收系统或其他任何东西时，这很容易。我看到项目失败了，因为他们无法从混乱的数据库中构建新的实例。主要的坏处是，它需要一些时间 - 在我们的情况下，由于我们的系统特别令人沮丧的细节，一个痛苦的长时间，但我认为一个真正在其工具之上的团队可以做一个完整的在10分钟内完成这样的重建。如果您有大量数据，则需要半小时。足够短，可以在一个工作日内做几次而不会自杀。
问题在于您对数据的处理方式。这有两个方面：开发过程中生成的数据和实时数据。
开发过程中生成的数据实际上非常简单。不按自己的方式工作的人可能习惯于直接在数据库中创建数据，因此看到一个问题，即重建时会丢失。解决方案很简单：您不在数据库中创建数据，而是在加载器脚本中创建数据（在我们的示例中为XML，但您可以使用SQL DML，或CSV与数据库的导入工具，或其他）。将加载器脚本视为源代码，将数据库视为目标代码：脚本是权威形式，是您手动编辑的;数据库是由他们制作的。
实时数据更加严格。我的公司还没有开发出适用于所有情况的单一流程 - 我不知道我们是否还没有找到魔法子弹，或者是否没有。我们的一个项目是采用与开发不同的方法，并且没有完全重建;相反，他们已经开发了一套实践，用于在制作新版本并手动应用时识别增量。它们每隔几周发布一次，因此对于几个人来说，这通常只需要几天的工作。不是很多。
我正在进行的项目尚未上线，但它正在取代现有的实时系统，因此我们遇到了类似的问题。我们的方法基于迁移：我们不是尝试使用现有数据库，而是将所有数据从它迁移到我们的系统中。我们编写了一个相当庞大的工具来执行此操作，它针对现有数据库（它的副本，而不是实时版本！）运行查询，然后将数据作为加载程序脚本写出。然后，这些就像其他任何进程一样进入构建过程。迁移是编写脚本的，并且每天晚上作为我们日常构建的一部分运行。在这种情况下，无论如何，编写此工具所需的工作是必要的，因为我们的数据库在结构上与旧数据库有很大不同;只需按一下按钮就可以进行可重复的迁移。
当我们上线时，我们的一个选择是调整此过程以从旧版本的数据库迁移到新版本。我们必须编写全新的查询，但它们应该非常简单，因为源数据库是我们自己的，并且从它到加载器脚本的映射，正如您想象的那样，直截了当，即使是新版本的系统偏离实时版本。这将让我们继续在完整的重建范例中工作 - 我们仍然不必担心ALTER TABLE或保持我们的数据库清洁，即使我们正在进行维护。不过，我不知道运营团队会想到这个想法！
答案 3 :(得分：0)
您可以使用数据库引擎的复制模块（如果有）
一台服务器将成为主服务器，将对其进行更改
开发人员副本将成为奴隶
主机上的任何更改都将在从机上重复。
这是单向复制。
由于对从站的任何更改都将被删除，因此可能会有点棘手。
这也意味着开发人员应该拥有两份数据库副本 一个是奴隶，另一个是“发展”数据库。
还有用于跨数据库复制的工具。 所以任何副本都可以成为主人。
这两种解决方案都可能导致灾难（复制错误）。
唯一的解决方案就是看，只有一个数据库供所有开发人员使用，并且每天在旋转历史记录上保存几次。
不会让你免于冲突，但是如果它发生的话，你将能够恢复以前的版本（它总是......）。
答案 4 :(得分：0)
在我工作的地方，我们使用的是Dotnetnuke，这也带来了同样的问题。即，一旦发布，生产站点就会有数据进入数据库，以及某些模块和DNN文件系统中正在添加到文件系统的文件。
我们正在使用svn对站点文件系统进行版本控制，这在大多数情况下都可以正常工作。但是，数据库是另一回事。到目前为止，我们遇到的最佳方法是使用RedGate工具将登台数据库与生产数据库同步。 RedGate工具非常好，物有所值。
基本上我们都在本地使用数据库和站点的本地副本进行开发。如果变化是主要的，我们分支。然后我们在本地提交并执行RedGate合并以将我们的数据库更改放在共享开发服务器上。
我们使用共享开发服务器，以便其他人可以进行测试。完成后，我们将使用svn在暂存时更新站点，然后将数据库更改从开发服务器合并到登台服务器。
然后上线我们也会从分期到生产做同样的事。
此方法有效但容易出错，并且在需要进行小的更改时非常耗时。 prod DB总是备份，因此如果交付出错，我们可以轻松回滚。
我们遇到的一个主要问题是，Dotnetnuke在许多表中使用了标识列，如果您有关于开发和生产的表格中的数据，例如标签和权限以及模块实例，那么您就会有噩梦同步它们。理想情况下，您希望查找或构建在数据库中使用GUI或其他内容的cms，以便您可以轻松同步正在使用的表。
我们很想找到更好的方法！因为当项目并发时我们在分支和合并方面遇到很多麻烦。
格斯