我正在寻找正确处理我的项目的mysql表跨环境更新的想法。我看了一下CI DB Forge类，我相信这个可能会对我有所帮助。我的想法是:
- 为每次数据库安装、表升级或更改创建一个新文件。该文件将包含执行每个相关任务的原始mysql查询
- 在加载任何控制器之前通过钩子运行升级脚本
- 继续加载项目
这是正确的想法吗?这与Magento处理每个扩展的数据库升级非常相似。
听起来您正在寻找Migrations类。这是一个相当新的库，在我看来，目前的文档不是很好。
如果您在application/config/migrations.php中启用这个库并加载它，它将创建一个名为migrations的数据库表。从那里开始的工作流如下:
- 在
application/migrations下创建一个新文件，确保使用按顺序编号的文件名命名，如001_some_descriptive_name.php。格式很重要，正好是3个数字，并且在它们之后至少有一个_。 - 在新文件中创建一个以文件名命名的类，因此
001_some_descriptive_name.php应该包含一个名为Migration_Some_descriptive_name的类并扩展CI_Migration类。类名的大小写很重要，首先是Migration_，然后是一个大写字母，然后是小写。 - 在类 中创建一个公共
- 在up方法中添加更改数据库的迁移代码。您可以使用db forge库或简单的旧式
$this->db->query()调用。如果你需要支持多个数据库系统，那么使用Dbforge可能会更好。 - 在
down方法中添加代码来逆转up的效果。如果up添加了一个列，那么down应该删除这个列，如果up创建了一个表，down应该删除这个表，以此类推。 - 一旦你完成了你的迁移类，在迁移配置文件中碰撞
migration_version。 - 创建一个控制器，加载迁移库并调用
$this->migration->current()，这将检查migration数据库表中的版本，并运行迁移类up或down方法，以便达到您在步骤6中设置的配置文件中的迁移版本。因此，例如，如果数据库显示您处于版本2，并且配置显示您应该处于版本5，那么它将按顺序运行003_...,004_...,005_..文件名的迁移的up方法。如果设置的数值较低，则当前的down方法将被调用。数据库从0开始计数，所以不要创建000_...文件。
up和一个公共down方法如果你觉得冒险，你可以创建一个钩子来加载迁移类，并在每次页面加载时运行get_instance()->migration->latest()，这样一旦你部署了一个新的迁移类，每个环境都会自动更新db。