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

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();