Paozhu 1.16.0 的重点不只是增加两个数据库驱动，而是把数据库切换进一步收敛到 ORM 和客户端框架内部。新版本的 ORM 已支持 MySQL、MariaDB、PostgreSQL 和 SQLite 四种数据库；PostgreSQL 客户端沿用了 MySQL 客户端中已经验证过的流程架构，并覆盖 socket、SSL 和 Unix socket 三种连接模式。
对业务代码而言，这意味着开发者可以在不大幅改动模型和查询逻辑的前提下切换数据库，同时选择同步调用或异步协程模式。数据库能力从“绑定某一个驱动”变成了应用部署时可以调整的基础设施选项。
统一数据库接口的价值
多数据库支持真正有价值的地方，不是让同一条 SQL 在任何数据库上都原样执行，而是让连接管理、模型映射、参数绑定和常见 CRUD 流程保持一致。
Paozhu 1.16.0 的 ORM 覆盖范围包括：
- MySQL
- MariaDB
- PostgreSQL
- SQLite
这几种数据库的定位并不相同。MySQL 和 MariaDB 更常见于长期运行的服务端系统，PostgreSQL 适合需要更强查询能力和数据类型支持的场景，SQLite 则适合本地工具、测试环境和轻量部署。统一 ORM 可以减少业务层对数据库驱动的直接依赖，但数据库差异仍然需要在建表语句、索引、事务行为和特有 SQL 上单独验证。
PostgreSQL 客户端覆盖三种连接方式
PostgreSQL 支持三种客户端连接模式：
socket：通过 TCP 连接数据库，适合常规服务部署。ssl：使用加密连接，适合跨主机或有传输安全要求的环境。unix.sock：通过 Unix domain socket 连接本机数据库，减少 TCP 配置并通常拥有较低的本机通信开销。
可以把连接方式放进配置文件，让同一份业务代码在开发、测试和生产环境使用不同连接参数。下面是一份可改造的配置示例。字段名称是配置层示意，实际项目应按照 Paozhu 1.16.0 的初始化 API 映射：
# config/database.yaml
active: postgres
connections:
mysql:
driver: mysql
mode: socket
host: 127.0.0.1
port: 3306
database: shop
user: app
password: change-me
postgres:
driver: postgresql
mode: ssl
host: 127.0.0.1
port: 5432
database: shop
user: app
password: change-me
sslmode: require
sqlite:
driver: sqlite
mode: file
path: ./var/shop.sqlite3
生产环境不应把数据库密码直接提交到代码仓库。可以保留配置结构，把 password 替换为环境变量或密钥管理系统提供的值。
同一业务逻辑切换数据库
以下示例展示一种适合接入 Paozhu ORM 的应用组织方式：业务服务只依赖 ORM 的连接和模型接口，具体数据库由配置选择。示例中的 paozhu::orm 名称用于表达接入边界，具体类名和初始化函数需要根据实际版本 API 调整。
// main.cpp
#include <cstdlib>
#include <iostream>
#include <string>
// 示例接口：请替换为 Paozhu 1.16.0 项目中的实际头文件和类型。
#include "paozhu/orm.hpp"
struct User {
long long id{};
std::string name;
};
int main() {
const char* url = std::getenv("DATABASE_URL");
if (url == nullptr) {
std::cerr << "DATABASE_URL is required\n";
return 1;
}
// 连接 URL 由部署环境决定，业务代码不需要改动。
auto db = paozhu::orm::connect(url);
auto users = db.query<User>(
"SELECT id, name FROM users WHERE active = ? ORDER BY id",
true
);
for (const auto& user : users) {
std::cout << user.id << " " << user.name << '\n';
}
return 0;
}
例如，开发环境可以这样运行 SQLite：
export DATABASE_URL='sqlite://./var/shop.sqlite3'
./shop-service
测试环境可以切换到 PostgreSQL：
export DATABASE_URL='postgresql://app:change-me@127.0.0.1:5432/shop?sslmode=require'
./shop-service
上面的 SQL 使用了常见的参数占位符，实际驱动可能要求不同的占位符形式，例如 PostgreSQL 常见的 $1、$2。因此，统一 ORM 的参数绑定层应优先使用框架提供的查询构造器或参数 API，不要在业务代码中手工拼接用户输入。
同步与协程模式的选择
Paozhu 1.16.0 同时支持同步和异步协程模式。同步模式适合后台任务、简单管理接口以及调用链本身不复杂的服务；协程模式则更适合一个请求需要访问多个外部服务，或者希望在等待数据库 I/O 时让出执行权的场景。
一个抽象的协程调用结构可以写成下面这样：
// 示例伪代码：具体协程函数名以项目实际 API 为准。
paozhu::task<Response> get_user(paozhu::request& request) {
auto id = request.path_parameter("id");
auto user = co_await database.query_one<User>(
"SELECT id, name FROM users WHERE id = ?",
id
);
if (!user) {
co_return Response::not_found();
}
co_return Response::json({
{"id", user->id},
{"name", user->name}
});
}
这里的关键不在于把所有查询都改成协程，而是保持数据库访问边界清晰：控制器负责请求和响应，服务层负责业务规则，ORM 负责模型和数据库交互。这样可以先用同步方式验证业务，再根据并发和延迟指标决定是否切换到协程。
迁移时需要验证什么
多数据库兼容不能只靠编译通过。迁移到 PostgreSQL 或 SQLite 时，应重点检查以下内容：
- 自增主键、布尔值、时间类型和 JSON 类型是否需要重新映射。
- MySQL 的反引号、字符串函数、分页语法和日期函数是否存在兼容问题。
- 事务隔离级别、锁行为和重复键错误是否满足业务预期。
- 索引、唯一约束和大小写规则在不同数据库中是否一致。
- SQLite 的并发写入能力是否适合生产负载。
- SSL 证书、Unix socket 路径和数据库用户权限是否已经纳入部署配置。
可以先准备一组跨数据库都能执行的基础 SQL，例如：
CREATE TABLE users (
id INTEGER PRIMARY KEY,
name VARCHAR(120) NOT NULL,
active BOOLEAN NOT NULL DEFAULT TRUE
);
INSERT INTO users (id, name, active) VALUES (1, 'Ada', TRUE);
这段 SQL 适合作为兼容性测试的起点，但不同数据库对 INTEGER PRIMARY KEY 和 BOOLEAN 的具体语义并不完全相同。正式迁移前，应通过 ORM 的迁移工具或分别维护数据库方言脚本，并用真实数据库执行测试。
采用建议
Paozhu 1.16.0 适合希望统一 C++ Web 服务数据库访问方式的团队。可以按以下顺序落地：
- 先在 SQLite 或测试数据库中验证模型、查询和迁移流程。
- 使用 PostgreSQL 或 MySQL 建立集成测试，覆盖事务、分页、唯一约束和错误处理。
- 将数据库连接模式放到部署配置中，分别验证 TCP、SSL 和 Unix socket。
- 先采用同步模式稳定业务，再根据监控数据评估协程模式。
- 对数据库特有能力保留清晰边界，避免为了“统一”而牺牲查询性能或数据正确性。
统一 ORM 降低了数据库切换成本，但不会消除数据库之间的行为差异。把兼容性测试、连接安全和 SQL 方言管理纳入工程流程，才能真正发挥 Paozhu 多数据库支持的价值。