【问题标题】:What's the best way to store a MySQL database in source control?在源代码管理中存储 MySQL 数据库的最佳方式是什么?
【发布时间】:2010-01-14 19:33:23
【问题描述】:

我正在与其他几个人一起开发一个应用程序,我们希望将我们的 MySQL 数据库存储在源代码控制中。我的想法是两个有两个文件:一个是表的创建脚本等,另一个是我们的示例数据的插入。这是一个好方法吗?另外,导出这些信息的最佳方式是什么?

此外,关于加快更改、导出、更新等过程的工作流程的任何建议。

【问题讨论】:

    标签: mysql database svn version-control


    【解决方案1】:

    这是我在 Subversion 下对 MySQL 数据库进行版本控制的过程。

    设置 SVN

    在 SVN 中为您希望添加到 SVN 的每个数据库创建一个带有子文件夹的 Databases 文件夹。

    将 db_version 表添加到数据库

    我们需要为每个数据库添加一个表,以便我们知道我们当前使用的数据库版本。此表还将用作日志来跟踪对数据库进行了哪些架构更改。

    create table db_version (
            `id` int auto_increment,
            `majorReleaseNumber` int,
            `minorReleaseNumber` int,
            `pointReleaseNumber` int,
            `scriptName` varchar(50),
            `dateApplied` datetime,
            PRIMARY KEY(`id`)
    );
    

    majorReleaseNumber - 主要版本是对数据库的重大更改。

    minorReleaseNumber - 次要版本是对数据库的增强,不需要主要版本。

    pointReleaseNumber - 点发布通常是一个简单的错误修复。

    scriptName - 使架构发生变化的 sql 脚本的名称。

    dateApplied - 脚本在此数据库上运行的时间。

    创建基线脚本

    我使用 mysqldump 为现有数据库生成创建脚本。请务必包含 --no-data 选项。 SVN 用于跟踪对数据库进行架构更改的脚本,而不是用作应用程序特定实例数据的备份工具。

    $ mysqldump -h localhost -u root -p db_1 --no-data > db_1.1.0.0.sql
    

    sql 脚本的名称应包含数据库名称和脚本适用的数据库版本。

    db_1.1.0.0.sql

    请务必在脚本末尾添加 db_version 表的插入语句。

    更改数据库架构

    当您对数据库进行主要、次要或点发布更改时,应测试更改脚本,然后将其上传到 SVN 中的数据库文件夹。在应用更改脚本之前备份数据库是个好主意。在更改脚本的末尾应该是 db_version 表的插入语句。

    【讨论】:

    • 在减少摩擦方面,我会考虑开发一个 shell 脚本,它可以自动确定和运行更新特定数据库实例所需的脚本。
    • @gWiz 感谢您的建议。我确实计划创建某种 db_sync 实用程序。
    【解决方案2】:

    这听起来是个好方法。您可以在表结构和数据方面区分各种修订。好的!

    创建转储的最佳方法可能是 **mysqldump**,因为它可以轻松自动化 - 一次使用 --no-data 获取创建语句,一次使用 --no-create-info --no-create-db 获取数据。

    【讨论】:

    • 另一种方法是使用--tab 选项到mysqldump。这将为架构创建一个<table-name>.sql 文件,并为数据创建一个制表符分隔的<table-name>.txt 文件。 Schema 像往常一样通过mysql 恢复,数据通过mysqlimport 恢复。 dev.mysql.com/doc/refman/5.1/en/mysqldump-delimited-text.html
    【解决方案3】:
    【解决方案4】:

    我在使用 Microsoft source safe 和 Oracle / Sql Server 的环境中工作。

    我们发现在单独的文本文件中保存每个包/过程、创建表脚本等是最好的方法。这意味着在维护包时,开发人员可以只签出他们需要的 1 个包等。进行更改并进行测试后,即可将其签入。

    【讨论】:

    • brrr,来源“安全”。我几乎投票 -1 只是因为在源代码控制的上下文中提及它 :-) 除此之外,这种方法是有效的,尽管不是我的建议。当然看看gWiz的回答中提到的链接。
    • 是的。我不会捍卫来源安全。它几乎完成了这项工作。也许我应该问一个关于迁移它(和所有历史)的问题,哈哈。这不是我想自愿参与的项目。
    【解决方案5】:

    你绝对有正确的想法。这里有几篇关于这个主题的好文章:

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2013-01-19
      • 2012-07-27
      • 1970-01-01
      • 2021-04-21
      • 1970-01-01
      • 2021-10-22
      • 1970-01-01
      • 2010-11-25
      相关资源
      最近更新 更多