7

我已经到了意识到我必须开始对我的数据库模式和更改进行版本控制的地步。因此，我阅读了关于该主题的现有帖子，但我不确定如何继续。

我基本上是一家单人公司，不久前我什至没有对我的代码使用版本控制。我在 Windows 环境中，使用 Aptana (IDE) 和 SVN (with Tortoise)。我从事 PHP/mysql 项目。

什么是对我的数据库模式进行版本控制的有效且足够（没有矫枉过正）的方法？

在某些项目中，我确实有一两个自由职业者，但我预计不会发生很多分支和合并。所以基本上我想跟踪我的代码修订的并发模式。

[编辑]临时解决方案：目前我决定只要我要提交一个标签（稳定版本），我就只做一个模式转储加上一个带有必要的初始数据的转储。在现阶段，这对我来说似乎已经足够了。[/edit]

[edit2]plus 我现在还使用了第三个名为 increments.sql 的文件，我将所有更改与日期等放在其中，以便在一个文件中轻松跟踪更改历史记录。我不时将更改集成到其他两个文件中并清空 increments.sql[/edit]

4

11 回答 11

7

小公司的简单方法：将您的数据库转储到 SQL 并将其添加到您的存储库中。然后每次更改某些内容时，将更改添加到转储文件中。

然后，您可以使用 diff 来查看版本之间的更改，更不用说注释解释您的更改了。这也将使您几乎不受 MySQL 升级的影响。

我看到的一个缺点是您必须记住手动将 SQL 添加到转储文件中。你可以训练自己永远记住，但如果你和别人一起工作要小心。错过更新以后可能会很痛苦。

这可以通过在提交颠覆时创建一些精心制作的脚本来为你做这件事来缓解，但这对于一个人的表演来说有点多。

编辑：在这个答案之后的一年里，我不得不为一个小团队实施 MySQL 版本控制方案。手动添加每个更改被视为一个繁琐的解决方案，就像评论中提到的那样，所以我们转储数据库并将该文件添加到版本控制中。

我们发现测试数据最终进入了转储，并且很难弄清楚发生了什么变化。这可以通过仅转储模式来解决，但这对于我们的项目来说是不可能的，因为我们的应用程序依赖于数据库中的某些数据才能运行。最终我们回到手动添加更改到数据库转储。

这不仅是最简单的解决方案，而且还解决了某些 MySQL 版本在导出/导入方面的某些问题。通常我们必须转储开发数据库，​​删除任何测试数据、日志条目等，在适用的情况下删除/更改某些名称，然后才能创建生产数据库。通过手动添加更改，我们可以准确地控制最终在生产中的结果，一次一点点，以便最终一切准备就绪，并且尽可能轻松地迁移到生产环境。

于 2009-04-16T11:32:11.207 回答
2

The main ideea is to have a folder with this structure in your project base path

/__DB
—-/changesets
——–/1123
—-/data
—-/tables

Now who the whole thing works is that you have 3 folders: Tables Holds the table create query. I recommend using the naming “table_name.sql”.

Data Holds the table insert data query. I recommend using the same naming “table_name.sql”. Note: Not all tables need a data file, you would only add the ones that need this initial data on project install.

Changesets This is the main folder you will work with. This holds the change sets made to the initial structure. This holds actually folders with changesets. For example i added a folder 1123 wich will contain the modifications made in revision 1123 ( the number is from your code source control ) and may contain one or more sql files.

I like to add them grouped into tables with the naming xx_tablename.sql - the xx is a number that tells the order they need to be runned, since sometimes you need the modification runned in a certain order.

Note: When you modify a table, you also add those modifications to table and data files … since those are the file s that will be used to do a fresh install.

This is the main ideea.

for more details you could check this blog post

于 2009-04-16T12:36:45.263 回答
2

这样做生成的版本控制文件怎么样：

mysqldump --no-data database > database.sql
于 2009-04-16T11:34:18.750 回答
2

在我工作的地方，我们为每个新版本的应用程序都有一个安装脚本，其中包含我们需要运行以进行升级的 sql。这对于 6 个开发人员来说已经足够好了，并且有一些维护版本的分支。我们正在考虑迁移到 Auto Patch http://autopatch.sourceforge.net/，它负责确定将哪些补丁应用于您正在升级的任何数据库。看起来可能有一些小的并发症处理分支与自动补丁，但听起来这对你来说不是问题。

于 2009-04-16T11:40:59.220 回答
2

我猜，像这样的批处理文件应该可以完成这项工作（没有尝试过）......

mysqldump --no-data -ufoo -pbar dbname > path/to/app/schema.sql
svn commit path/to/app/schema.sql

只需在更改架构后运行批处理文件，或者让 cron/调度程序执行它（但我不知道......我认为，如果只是时间戳更改，即使内容相同，提交也可以工作。不要知道这是否会是一个问题。）

于 2009-04-16T12:15:37.683 回答
1

几个月前，我搜索了 MySQL 模式版本控制工具。我发现了很多有用的工具，比如 Doctrine 迁移、RoR 迁移、一些用 Java 和 Python 编写的工具。

但是没有一个能满足我的要求。

我的要求：

  1. 无要求，不包括 PHP 和 MySQL
  2. 没有模式配置文件，如 Doctrine 中的 schema.yml
  3. 能够从连接中读取当前模式并创建新的迁移脚本，而不是在其他应用程序安装中表示相同的模式。

我开始写我的迁移工具，今天我有测试版。

如果您对此主题感兴趣，请尝试一下。请向我发送未来的请求和错误报告。

源代码：bitbucket.org/idler/mmp/src 英文概述：bitbucket.org/idler/mmp/wiki/Home 俄文概述：antonoff.info/development/mysql-migration-with-php-project

于 2010-07-07T21:27:11.627 回答
1

在我们公司，我们是这样做的：

我们将所有表/数据库对象放在它们自己的文件中，例如tbl_Foo.sql. 这些文件包含几个用分隔的“部分”

-- part: create

其中create只是给定部分的描述性标识，文件如下所示：

-- part: create
IF not exists ...
CREATE TABLE tbl_Foo ...
-- part: addtimestamp
IF not exists ...
BEGIN
   ALTER TABLE ...
END

然后我们有一个 xml 文件，它引用我们在将数据库更新到新模式时要执行的每个部分。它看起来很像这样：

<playlist>
   <classes>
     <class name="table" desc="Table creation" />
     <class name="schema" desc="Table optimization" />
   </classes>
   <dbschema>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="create" class="table" />
         <step file="tbl_Bar.sql" part="create" class="table" />
      </steps>
      <steps db="a_database">
         <step file="tbl_Foo.sql" part="addtimestamp" class="schema" />
      </steps>
   </dbschema>          
</playlist>

<classes/>对于 GUI 和<dbschema/>with的部分<steps/>是对更改进行分区。: <step/>s 是按顺序执行的。我们还有其他一些实体，喜欢sqlclr做不同的事情，比如部署二进制文件，但仅此而已。

当然，我们有一个组件来获取该播放列表文件和一个资源/文件系统对象，该对象交叉引用播放列表并取出想要的部分，然后在数据库上以管理员身份运行它们。

由于 .sql 中的“部分”是这样编写的，因此它们可以在任何版本的 DB 上执行，我们可以在每个以前/旧版本的 DB 上运行所有部分并将其修改为最新版本。当然，在某些情况下，SQL Server 会“提前”解析列名，我们必须稍后将部分修改为exec_sqls，但这种情况并不经常发生。

于 2009-04-18T11:54:27.083 回答
1

我们的解决方案是 MySQL Workbench。我们定期将现有数据库逆向工程为具有适当版本号的模型。然后可以根据需要轻松执行版本之间的差异。另外，我们得到了很好的 EER 图等。

于 2010-07-07T21:31:00.387 回答
1

看看SchemaSync。随着时间的推移，它将生成迁移和版本化数据库架构所需的补丁和恢复脚本（.sql 文件）。它是一个独立于语言和框架的 MySQL 命令行实用程序。

于 2010-04-15T22:01:34.287 回答
1

我认为这个问题值得一个现代的答案，所以我要自己给出。当我在 2009 年写下这个问题时，我不认为Phinx已经存在，而且 Laravel 绝对没有。

今天，这个问题的答案非常明确：编写增量数据库迁移脚本，每个脚本都有一个up和一个down方法，并在安装或更新应用程序时运行所有这些脚本或它们的增量。并且显然将迁移脚本添加到您的 VCS。

如开头所述，当今 PHP 世界中有很多出色的工具可以帮助您轻松管理迁移。Laravel 内置了数据库迁移，包括相应的 shell 命令。其他人都有一个与 Phinx 类似的强大的与框架无关的解决方案。

Artisan 迁移 (Laravel) 和 Phinx 的工作方式相同。对于数据库中的每一次更改，创建一个新的迁移，使用普通 SQL 或内置查询构建器来编写 up 和 down 方法并运行artisan migrateresp。phinx migrate在控制台中。

于 2015-03-13T01:43:51.930 回答
0

我做了一些类似于 Manos 的事情，除了我有一个定期更新的“主”文件 (master.sql)（每 2 个月一次）。然后，对于每次更改，我都会使用更改构建一个名为 .sql 文件的版本。这样，我可以从 master.sql 开始并添加每个名为 .sql 文件的版本，直到我升级到当前版本，并且我可以使用名为 .sql 文件的版本更新客户端以使事情变得更简单。

于 2009-08-03T12:24:55.957 回答