dia*_*ich 11 mysql database collaboration version-control process
在数据库网站上的小团队中进行协作时,您采取了哪些流程？
我们在站点文件上工作没有任何问题,因为它们处于版本控制之下,因此任何数量的开发人员都可以在网站的这个方面从任何位置工作.
但是,当需要进行数据库更改时(直接作为开发的一部分或通过在CMS中进行内容更改而隐式),显然不同的开发人员很难合并这些数据库更改.
到目前为止,我们的方法仅限于以下方面:
我很想知道你是否有更好的建议.
我们主要使用MySQL数据库,目前不跟踪这些数据库的修订.上面讨论的问题主要涉及Drupal和Wordpress站点,其中大量的"开发"与CMS中的数据库所做的更改一起执行.
在我工作的地方，每个开发人员（实际上，每个开发虚拟机）都有自己的数据库（或者更确切地说，在共享 Oracle 实例上有自己的模式）。我们的工作流程基于完整的重建。我们没有任何能力修改现有的数据库——我们唯一的选择就是放弃整个模式并从头开始构建。
我们有一个“删除所有内容”的小脚本，它使用系统表上的查询来识别模式中的每个对象，构建一堆 SQL 来删除它们，然后运行它。然后我们有一堆充满 CREATE TABLE 语句的 DDL 文件，然后我们有一堆包含系统初始数据的 XML 文件，这些文件由加载工具加载。所有这些都被检查到源代码管理中。当开发人员从源代码控制进行更新时，如果他们看到传入的数据库更改（DDL 或数据），他们会运行主构建脚本，该脚本运行它们以便从头开始创建新的数据库。
好处是这让生活变得简单。我们永远不需要担心差异、增量、ALTER TABLE、可逆性等，只需简单的 DDL 和数据。我们永远不必担心保留数据库的状态或保持其干净 - 您只需按一下按钮即可恢复到干净的状态。另一个重要的特点是，它使得建立一个新平台变得微不足道——这意味着当我们添加更多的开发机器，或者需要构建一个验收系统或其他什么时，这很容易。我见过一些项目失败，因为他们无法从混乱的数据库中构建新实例。
主要的坏处是，这需要一些时间 - 在我们的例子中，由于我们系统的特定令人沮丧的细节，这是一个痛苦的漫长时间，但我认为一个真正掌握其工具的团队可以像这样进行完整的重建10 分钟后。如果数据量大的话半小时。足够短，可以在一个工作日内做几次而不会自杀。
问题在于你如何处理数据。这有两个方面：开发过程中生成的数据和实时数据。
开发过程中生成的数据实际上非常简单。不按照我们的方式工作的人可能习惯于直接在数据库中创建该数据，因此会看到一个问题，即重建时数据会丢失。解决方案很简单：您不在数据库中创建数据，而是在加载器脚本中创建数据（在我们的示例中为 XML，但您可以使用 SQL DML，或通过数据库的导入工具使用 CSV，或其他工具）。将加载器脚本视为源代码，将数据库视为目标代码：脚本是最终形式，并且是您手动编辑的内容；数据库就是由它们组成的。
实时数据更加困难。我的公司还没有开发出一种适用于所有情况的单一流程 - 我不知道我们是否还没有找到灵丹妙药，或者是否没有。我们的一个项目采取的方法是，生活与开发不同，并且没有完全重建；相反，他们开发了一套实践，用于在制作新版本时识别增量并手动应用它们。他们每隔几周发布一次，因此对于几个人来说通常只需几天的工作。不是很多。
我正在进行的项目还没有上线，但它正在替换现有的上线系统，所以我们也有类似的问题。我们的方法基于迁移：我们不是尝试使用现有数据库，而是将所有数据从现有数据库迁移到我们的系统中。我们编写了一个相当庞大的工具来执行此操作，它对现有数据库（数据库的副本，而不是实时版本！）运行查询，然后将数据作为加载器脚本写出。然后，它们就像其他任何东西一样进入构建过程。迁移是有脚本的，并且作为我们日常构建的一部分每晚运行。在这种情况下，无论如何，编写这个工具所需的努力是必要的，因为我们的数据库在结构上与旧数据库有很大不同；只需按一下按钮即可免费进行可重复迁移。
当我们上线时，我们的选择之一是调整此过程以从旧版本的数据库迁移到新版本。我们必须编写全新的查询，但它们应该非常容易，因为源数据库是我们自己的，并且从它到加载器脚本的映射正如您想象的那样简单，即使是新版本的系统偏离了实时版本。这将使我们继续在完整的重建范例中工作 - 即使我们正在进行维护，我们仍然不必担心 ALTER TABLE 或保持数据库干净。不过，我不知道运营团队会如何看待这个想法！