本文的目的是使用库的示例 模式管理员 展示可以显着简化使用 PostgreSQL DBMS 在 PHP 项目中开发数据库的过程的工具。

首先，本文中的信息对于想要充分利用 PostgreSQL 功能但在维护数据库中的业务逻辑时面临问题的开发人员很有用。

本文不会描述将业务逻辑存储在数据库中的优点或缺点。 假设读者已经做出选择。

将考虑以下问题：

1. 数据库结构转储应该以什么形式存储在版本控制系统（以下简称VCS）中
2. 保存转储后如何跟踪数据库结构的变化
3. 如何将数据库结构的变化转移到其他环境而不发生冲突和巨大的迁移文件
4. 如何组织多个开发人员在项目上并行工作的过程
5. 如何将数据库结构的更多变化安全地部署到生产环境
   

   模式管理器 设计用于处理用该语言编写的存储过程 PL/pgSQL。 尚未进行其他语言的测试，因此使用可能不那么有效或可能无法实现。

如何在 VCS 中存储数据库结构转储

图书馆 模式管理员 提供一个函数 saveDump，它将数据库中所有对象的结构保存为单独的文本文件。 输出是一个包含数据库结构的目录，分为可以轻松添加到 VCS 的分组文件。

让我们使用几个示例来了解如何将数据库中的对象转换为文件：

对象类型
方案
名称
文件的相对路径

表
国家
账户
./public/tables/accounts.txt

存储过程
国家
验证（哈希bigint）
./public/functions/auth(int8).sql

主意
预订
关税
./booking/views/tariffs.txt

文件的内容是特定数据库对象结构的文本表示。 例如，对于存储过程，文件的内容将是存储过程的完整定义，从块开始 CREATE OR REPLACE FUNCTION.

从上表可以看出，文件的路径存储了对象的类型、模式和名称等信息。 这种方法可以更轻松地浏览数据库中更改的转储和代码审查。

延期 .sql 对于带有存储过程源代码的文件，选择此项是为了在打开文件时 IDE 自动提供与数据库交互的工具。

保存转储后如何跟踪数据库结构的变化

通过在 VCS 中保存当前数据库结构的转储，我们有机会检查创建转储后是否对数据库结构进行了更改。 在图书馆 模式管理员 为了检测数据库结构的变化，提供了一个函数 verifyDump，它返回有关差异的信息，而没有副作用。

另一种检查方法是再次调用该函数 saveDump，指定相同的目录，并在 VCS 中检查更改。 由于数据库中的所有对象都保存在单独的文件中，VCS 将仅显示更改的对象。
此方法的主要缺点是需要覆盖文件才能看到更改。

如何将数据库结构的变化转移到其他环境而不发生冲突和巨大的迁移文件

感谢功能 deployDump 存储过程的源代码可以按照与常规应用程序源代码完全相同的方式进行编辑。 您可以在存储过程代码中添加/删除新行并立即将更改推送到版本控制，或者通过在转储目录中创建/删除相应文件来创建/删除存储过程。

例如，要在架构中创建新的存储过程 public 只需创建一个带有扩展名的新文件 .sql 在目录中 public/functions，将存储过程的源代码放入其中，包括块 CREATE OR REPLACE FUNCTION，然后调用该函数 deployDump。 修改和删除存储过程的方式相同。 因此，代码同时进入 VCS 和数据库。

如果任何存储过程的源代码中出现错误，或者文件名与存储过程的名称不一致，则 deployDump 将失败，并显示错误文本。 使用时，转储和当前数据库之间的存储过程不匹配是不可能的 deployDump.

创建新的存储过程时，无需手动输入正确的文件名。 文件有扩展名就足够了 .sql。 通话结束后 deployDump 错误文本将包含正确的名称，可用于重命名文件。

deployDump 允许您更改函数的参数或返回类型，而无需执行其他操作，而使用经典方法时，您必须
首先执行 DROP FUNCTION，只有那时 CREATE OR REPLACE FUNCTION.

不幸的是，在某些情况下 deployDump 无法自动应用更改。 例如，如果至少一个触发器使用的触发器功能被移除。 此类情况可以使用迁移文件手动解决。

如果您负责将更改迁移到存储过程 模式管理员，那么必须使用迁移文件来传输结构中的其他更改。 例如，一个用于处理迁移的优秀库是 学说/迁移.

必须在启动前应用迁移 deployDump。 这使您可以对结构进行所有更改并解决有问题的情况，以便随后可以毫无问题地传输存储过程中的更改。

以下各节将更详细地描述如何使用迁移。

如何组织多个开发人员在项目上并行工作的过程

有必要创建一个脚本来完成数据库的初始化，该脚本将由开发人员在他的工作计算机上启动，使本地数据库的结构与VCS中保存的转储一致。 最简单的方法就是将本地数据库的初始化分为3步：

1. 导入具有基本结构的文件，例如 base.sql
2. 应用迁移
3. 通话 deployDump

base.sql 是应用和执行迁移的起点 deployDump即， base.sql + миграции + deployDump = актуальная структура БД。 您可以使用该实用程序创建这样的文件 pg_dump。 用过的 base.sql 仅在从头开始初始化数据库时。

让我们调用该脚本来完成数据库初始化 refresh.sh。 工作流程可能如下所示：

1. 开发人员在他的环境中启动 refresh.sh 并获取当前数据库结构
2. 开发人员开始处理手头的任务，修改本地数据库以满足新功能的需求（ALTER TABLE ... ADD COLUMN 等等）
3. 完成任务后，开发者调用该函数 saveDump提交对 VCS 中的数据库所做的更改
4. 开发者重新启动 refresh.sh然后 verifyDump现在显示了要包含在迁移中的更改列表
5. 开发人员将所有结构更改传输到迁移文件，再次运行 refresh.sh и verifyDump，并且，如果迁移编译正确， verifyDump 将显示本地数据库和保存的转储之间没有差异

上述过程与 gitflow 原则兼容。 VCS 中的每个分支都将包含其自己的转储版本，并且在合并分支时，转储将被合并。 在大多数情况下，合并后不需要执行任何其他操作，但如果在不同分支中进行更改（例如，对同一个表进行更改），则可能会出现冲突。

让我们用一个例子来考虑冲突情况：有一个分支 开发，从中分支出两个分支： feature1 и feature2，这与没有冲突 开发，但又互相冲突。 任务是将两个分支合并为 开发。 对于这种情况，建议首先将其中一个分支合并到 开发然后合并 开发 到剩余分支，解决剩余分支中的冲突，然后将最后一个分支合并到 开发。 在冲突解决阶段，您可能必须修复最后一个分支中的迁移文件，以便它与最终转储（包括合并结果）匹配。

如何将数据库结构的更多变化安全地部署到生产环境

由于 VCS 中存在当前数据库结构的转储，因此可以检查生产数据库是否完全符合所需的结构。 这确保了开发人员预期的所有更改都成功转移到生产基地。

如 DDL 在 PostgreSQL 中是 交易性的，建议遵循以下部署顺序，这样，万一出现意外错误，可以“无痛”执行 ROLLBACK:

1. 开始交易
2. 执行事务中的所有迁移
3. 在同一事务中，执行 deployDump
4. 未完成交易，执行 verifyDump。 如果没有错误，运行 COMMIT。 如果有错误，则运行 ROLLBACK

这些步骤可以轻松集成到现有的应用程序部署方法中，包括零停机时间。

结论

通过上述方法，与在主应用程序代码中实现所有业务逻辑相比，可以从“PHP + PostgreSQL”项目中获得最大性能，同时牺牲相对较小的开发便利性。 此外，数据处理 PL/pgSQL 与用 PHP 编写的相同功能相比，通常看起来更透明并且需要更少的代码。

来源： habr.com