C++ ORM 多数据库异构混合使用 同一项目同时连接 MySQL、PostgreSQL 和 SQLite

Paozhu ORM 可以多种不同数据库混合一起使用，满足项目多种业务代码，比如临时拼搭，Paozhu ORM 提供dbconver 转换命令，可以MySQL、PostgreSQL 和 SQLite 数据库之间无缝迁移。

业务代码都无需更改自动适应目标数据库，更换目标代码后重新生成适应方言数据库中间层。

Paozhu ORM 是C++ ORM已经部分达顶级设计，比如数据库dbconver dbexport dbtable 命令数据库管理工具提供各种数据库迁移合并。

Paozhu ORM 的生成ORM代码和数据库管理命令分开，Paozhu ORM生产环境时候可以不依赖数据库管理命令运行。

Paozhu ORM conf/orm.conf配置，支持主从读写分离,cms pg 标签是不同数据库配置，cms pg 标签用来生成命名空间隔离数据库，防止数据库表重名。

[cms]
type     = main
host     = 127.0.0.1
port     = 3306
dbname   = cppcms
user     = root
password = 12345678
pretable = 
maxpool  = 5
dbtype   = mysql
charset  = utf8mb4

type     = second
host     = 127.0.0.1
port     = 3306
dbname   = cppcms
user     = root
password = 12345678
pretable = 
maxpool  = 20
dbtype   = mysql
charset  = utf8mb4

[pg]
type     = main
host     = 127.0.0.1
port     = 5432
dbname   = hello_world
user     = hello
password = 12345678
pretable = 
maxpool  = 5
dbtype   = postgresql
charset  = utf8
#ssl=ON
#sslverify=ON                    ; 校验证书链（配合系统 CA / SSL_CERT_FILE）
#sslhost=db.example.com          ; 证书域名（SNI + 域名校验），为空则只验证链不校验域名

type     = second
host     = 127.0.0.1
port     = 5432
dbname   = hello_world
user     = hello
password = 12345678
pretable = 
maxpool  = 20
dbtype   = postgresql
charset  = utf8
#ssl=ON
#sslverify=ON
#sslhost=db.example.com

Paozhu ORM 、Drogon ORM、ORMPP比较。

Paozhu ORM 在这一维度上确实展现出了独特的架构优势。以下是针对“多数据库混合使用”的深度解析：

1. Paozhu ORM：编译期多态 + 统一接口 (原生支持)

Paozhu 的核心设计是将数据库类型作为模板参数注入到 ORM 引擎层，而非运行时动态分发。

• 模型级绑定：每个生成的 Model 类在编译期就绑定了特定的数据库类型（如 mysql_tag 或 postgres_tag）。
• 统一 API 表面：无论底层是哪种数据库，上层调用的 .eqId(1).async_fetch() 接口完全一致。SQL 方言差异（如分页 LIMIT vs OFFSET/FETCH、引号风格）在模板特化中于编译期解决。
• 零运行时开销：没有虚函数表查找，没有 if (db_type == mysql) 的运行时分支判断。混合使用时，编译器为每种数据库生成独立的优化代码路径。
• 独立连接池：每种数据库类型拥有独立的、类型安全的连接池实例，互不干扰，且都支持异步协程。

// Paozhu: 无缝混合，API 完全一致，编译期确定
auto mysql_user = co_await UserMysql().eqId(1).async_fetch();      // MySQL 连接池
auto pg_order  = co_await OrderPg().eqUserId(1).async_fetch();     // PostgreSQL 连接池
auto sqlite_log = co_await LogSqlite().descTime().limit(100).async_fetch(); // SQLite 连接池

实际上，paozhu已经帮你生成好 mysql_user pg_order sqlite_log 了，放在models目录，无需自己手动创建，每一个表名就是一个对象，使用命名空间隔开。

2. ORMPP：模板切换可行，但工程化割裂

ORMPP 通过 dbng<T> 模板支持多数据库，但在实际混合使用时存在明显短板：

• API 不完全统一：虽然 CRUD 接口相似，但复杂查询（JOIN、子查询、特定函数）往往需要针对不同数据库手写不同的 SQL 片段，因为 ORMPP 缺乏编译期 SQL 方言适配层。
• 同步阻塞瓶颈：dbng<mysql> 和 dbng<postgresql> 都是同步阻塞的。在高并发混合查询场景下，你必须为每种数据库分别管理线程池或异步包装器，极易造成资源竞争和死锁。
• 无统一事务/连接管理：跨库操作时，没有内置的连接生命周期协调机制，需手动管理多个 dbng 实例的连接与释放。

// ORMPP: 能混用，但体验割裂
dbng<mysql> mysql_db;
dbng<postgresql> pg_db;
// 查询接口相同，但复杂SQL需手写不同方言
// 且均为同步阻塞，高并发下需额外封装异步层

3. Drogon ORM：手动管理多 Client (繁琐)

Drogon 的多数据库支持是“可用但笨重”的：

• 手动创建 DbClient：必须为每种数据库显式创建并命名 DbClientPtr，然后在每次查询时手动传入。
• Model 不绑定数据库：同一个 Model 类可以被任意 DbClient 使用，这带来了灵活性，但也意味着编译器无法检查数据库类型匹配。将 MySQL 的 Model 误传给 PostgreSQL 的 Client，只能在运行时报错。
• Criteria 方言局限：Criteria 对象是通用的，对于数据库特有的语法（如 PG 的 JSONB 操作、MySQL 的 ON DUPLICATE KEY），仍需回退到手写 SQL。
• 配置驱动：多数据库配置集中在 JSON/YAML 中，代码中通过字符串名称引用，重构时容易遗漏。

// Drogon: 手动传递 Client，无编译期类型安全
auto mysql_client = drogon::app().getDbClient("mysql");
auto pg_client = drogon::app().getDbClient("postgres");

// 必须手动指定 client，传错不会编译报错
auto user = co_await Mapper<User>(mysql_client).findBy(Criteria(...));
auto order = co_await Mapper<Order>(pg_client).findBy(Criteria(...));

📊 多数据库混合使用能力对比总结

维度	Paozhu ORM	ORMPP	Drogon ORM
混合使用方式	✅ 模型级编译期绑定，API 统一	⚠️ 模板切换，API 部分统一	⚠️ 手动传递 DbClient，API 统一
SQL 方言适配	✅ 编译期模板特化自动处理	❌ 复杂查询需手写不同 SQL	⚠️ Criteria 通用，特殊语法需手写
类型安全	✅ 编译期检查 DB 类型匹配	⚠️ 模板参数检查	❌ 运行时检查，易传错 Client
异步混合查询	✅ 原生协程，独立连接池	❌ 同步阻塞，需额外封装	✅ 原生协程，但需手动管理 Client
连接池隔离	✅ 自动按 DB 类型隔离	⚠️ 手动管理多个 dbng 实例	✅ 按名称隔离，但需手动获取
跨库事务	❌ 不支持 (业界通病)	❌ 不支持	❌ 不支持
开发体验	🟢 无缝透明	🟡 简单场景好，复杂场景差	🟡 繁琐，易出错

💡 为什么 Paozhu 能做到"无缝混合"？

核心在于其三层架构中的 OpSql 层是一个以数据库类型为模板参数的 CRTP 基类：

// 伪代码示意 Paozhu 架构
template<typename Model, typename DbTag>
class fk_parent_opsql : public fk_parent_base<Model> {
    // DbTag 决定：
    // 1. 使用哪个连接池
    // 2. SQL 拼接规则 (引号、分页、类型转换)
    // 3. 预编译语句的绑定方式
};

// 用户模型继承时已绑定具体数据库
class UserMysql : public fk_parent_opsql<UserMysql, mysql_tag> {};
class OrderPg   : public fk_parent_opsql<OrderPg, postgres_tag> {};

这种设计使得数据库差异在编译期被完全消除，上层业务代码看到的是完全统一的、类型安全的异步接口。而 ORMPP 和 Drogon 要么将差异推迟到运行时（Drogon），要么将差异暴露给用户手动处理（ORMPP）。

paozhu ORM简单的代码演示，根据不同lite标签可以混合不同的数据库，使用标签做命名空间。

    auto articles = orm::lite::Fortune();
    int aid       = client.get["id"].to_int(); //获取URL ?id=1 这种模式
    articles.where("id", aid).fetch_one();

🎯 结论

如果你的项目涉及两种及以上数据库的混合使用，尤其是需要在高并发异步环境下透明地访问不同数据源：

• Paozhu ORM 是目前 C++ 生态中唯一做到编译期安全、零运行时开销、API 完全统一的选择。
• Drogon ORM 可以胜任，但需要忍受手动管理 Client 和运行时类型检查的风险。
• ORMPP 仅适合低并发、简单 CRUD 的多数据库场景，复杂混合查询会迅速退化到手写 SQL。

⚠️ 注意：三者均不支持真正的跨数据库分布式事务。如需跨库事务一致性，仍需依赖外部方案（如 Seata、XA 协议或应用层补偿机制）。Paozhu 的优势仅限于数据访问层的无缝混合，而非事务协调层。