第17章数据库集成

课程目录第17章数据库集成

17、数据库集成：SQLite 与 SOCI 库，连接池设计，ORM 框架（ODB）简介

数据库集成，说白了就是让C++程序能跟数据库说上话。很多新手觉得这步就是调个API，但我在大型项目里踩过的坑告诉我——这里面的门道，远比想象中多。今天咱们就聊聊SQLite、SOCI库、连接池，还有ODB这个ORM框架。

17.1 SQLite：轻量级嵌入式数据库

SQLite是个好东西。它不需要独立服务进程，直接读写文件就行。我最早接触它是在一个嵌入式设备项目里，那时候内存只有64MB，跑MySQL简直是天方夜谭。SQLite的库文件才几百KB，完美契合。

但要注意，SQLite不是万能的。它适合单机、低并发场景。如果你要搞高并发写入，那还是趁早换PostgreSQL吧。

核心特点：

零配置：不需要安装、不需要管理员
单文件存储：整个数据库就是一个.db文件
支持SQL标准：大部分SQL语法都支持
事务支持：ACID特性完整

使用SQLite的C API其实挺原始的。你得手动管理连接、准备语句、绑定参数、清理资源。我早期项目就这么干，结果代码里到处都是sqlite3_open、sqlite3_prepare_v2、sqlite3_finalize……维护起来简直噩梦。

// 原生SQLite API示例
sqlite3 *db;
sqlite3_open("test.db", &db);

sqlite3_stmt *stmt;
sqlite3_prepare_v2(db, "SELECT id, name FROM users WHERE age > ?", -1, &stmt, nullptr);
sqlite3_bind_int(stmt, 1, 18);

while (sqlite3_step(stmt) == SQLITE_ROW) {
    int id = sqlite3_column_int(stmt, 0);
    const char *name = (const char *)sqlite3_column_text(stmt, 1);
    // 处理数据
}

sqlite3_finalize(stmt);
sqlite3_close(db);

看到没？光一个查询就要写这么多行。而且你想想看，如果每个数据库操作都这么写，项目里得有多少重复代码？

17.2 SOCI库：C++数据库访问层

SOCI就是来解决这个问题的。它是一个C++数据库访问库，提供了统一的接口，底层可以切换SQLite、MySQL、PostgreSQL等。我个人习惯用SOCI，因为它让代码干净很多。

我的经验：SOCI的编译需要依赖对应数据库的客户端库。比如用SQLite后端，就要链接libsqlite3。我第一次编译时忘了装开发包，折腾了半小时才反应过来。

// SOCI + SQLite 示例
#include <soci/soci.h>
#include <soci/sqlite3/soci-sqlite3.h>

soci::session sql(soci::sqlite3, "test.db");

// 创建表
sql << "CREATE TABLE IF NOT EXISTS users ("
       "id INTEGER PRIMARY KEY, "
       "name TEXT NOT NULL, "
       "age INTEGER)";

// 插入数据
sql << "INSERT INTO users(name, age) VALUES(:name, :age)",
    soci::use("张三"), soci::use(25);

// 查询数据
soci::rowset<soci::row> rs = (sql.prepare << "SELECT id, name, age FROM users WHERE age > :minAge",
                               soci::use(18));

for (auto &row : rs) {
    int id = row.get<int>(0);
    std::string name = row.get<std::string>(1);
    int age = row.get<int>(2);
    // 处理数据
}

你看，代码简洁多了。参数绑定用:name这种命名方式，比问号占位符更直观。而且SOCI自动管理资源，不用手动释放语句句柄。

不过SOCI也有坑。我记得有一次项目里用了SOCI的批量插入，结果发现它内部是逐条执行的，性能很差。后来我改用事务包裹，才把速度提上来。

避坑指南：SOCI的rowset是懒加载的。如果你在遍历过程中修改了数据库，可能会导致迭代器失效。我曾经因为这个bug排查了两天。

17.3 连接池设计

连接池，说白了就是预先创建一批数据库连接，用的时候拿一个，用完还回去。为什么要这么做？因为创建数据库连接是个昂贵操作——尤其是网络数据库，握手、认证、分配资源，一套下来几十毫秒就没了。

我参与过一个游戏服务器项目，高峰时每秒上千次数据库操作。如果每次请求都新建连接，服务器直接卡死。后来我们设计了连接池，问题迎刃而解。

一个简单的连接池设计思路：

class ConnectionPool {
public:
    ConnectionPool(const std::string& connStr, int poolSize)
        : connStr_(connStr), poolSize_(poolSize) {
        for (int i = 0; i < poolSize_; ++i) {
            auto* conn = new soci::session(soci::sqlite3, connStr_);
            idle_.push(conn);
        }
    }

    soci::session* acquire() {
        std::unique_lock<std::mutex> lock(mutex_);
        while (idle_.empty()) {
            cond_.wait(lock);
        }
        auto* conn = idle_.front();
        idle_.pop();
        return conn;
    }

    void release(soci::session* conn) {
        std::lock_guard<std::mutex> lock(mutex_);
        idle_.push(conn);
        cond_.notify_one();
    }

private:
    std::string connStr_;
    int poolSize_;
    std::queue<soci::session*> idle_;
    std::mutex mutex_;
    std::condition_variable cond_;
};

这个实现虽然简单，但核心思想都在了：

预创建连接，避免运行时开销
互斥锁保护，线程安全
条件变量通知，避免忙等待

我的建议：连接池大小不是越大越好。我见过有人设了200个连接，结果数据库服务器扛不住。一般经验是：连接数 = (CPU核心数 * 2) + 磁盘数。当然，具体还得压测。

另外，连接池还要考虑连接有效性检测。如果数据库重启了，池里的连接就失效了。我习惯在acquire时做一次轻量查询（比如SELECT 1），如果失败就重建连接。

17.4 ORM框架（ODB）简介

ORM，对象关系映射。说白了就是把数据库表映射成C++类，让你用操作对象的方式操作数据库。ODB是C++里比较成熟的ORM框架。

我第一次用ODB是在一个金融项目里。那项目有几十张表，手写SQL映射代码简直要命。ODB能自动生成代码，省了我不少时间。

ODB的工作方式是这样的：

你定义C++类，用ODB的注解标记映射关系
ODB编译器读取这些注解，生成数据库操作代码
你只需要调用生成的API，不用写SQL

// ODB 实体定义
#pragma db object
class User {
public:
    User() {}

    #pragma db id auto
    unsigned long id_;

    std::string name_;
    int age_;
};

// 使用ODB
#include <odb/database.hxx>
#include <odb/sqlite/database.hxx>
#include "user-odb.hxx"

odb::database* db = new odb::sqlite::database("test.db");

// 插入
std::unique_ptr<User> u(new User("李四", 30));
unsigned long id = db->persist(*u);

// 查询
typedef odb::query<User> query;
typedef odb::result<User> result;

result r = db->query<User>(query::age > 18);
for (auto& user : r) {
    std::cout << user.name_ << std::endl;
}

看到没？代码里完全没有SQL字符串。ODB帮你生成了persist、query、update、erase这些方法。而且它是编译期生成的，性能比运行时反射好很多。

注意：ODB的学习曲线有点陡。它需要额外的编译步骤（odb编译器），而且生成的代码量很大。我建议在表结构稳定后再引入ODB，否则频繁改表会让人崩溃。

ODB支持多种数据库后端：SQLite、MySQL、PostgreSQL、Oracle等。切换后端只需要改一下数据库驱动，代码几乎不用动。这一点在项目后期换数据库时特别有用。

不过ORM也不是银弹。复杂查询（比如多表联查、子查询）用ORM写起来反而更麻烦。我一般的原则是：简单CRUD用ORM，复杂查询用SOCI直接写SQL。

17.5 本章小结

数据库集成这块，我建议你按这个思路来：

小项目、单机场景：SQLite + SOCI，简单够用
中大型项目：连接池是必须的，别偷懒
表结构复杂、CRUD多：考虑ODB，但要做好编译配置
性能敏感场景：直接写SQL，ORM的抽象有开销

嗯，这些就是我这些年积累下来的经验。数据库集成看似基础，但做不好会引发连锁问题——连接泄漏、性能瓶颈、事务混乱……希望你能少走些弯路。

📚 课程目录

17、数据库集成：SQLite 与 SOCI 库，连接池设计，ORM 框架（ODB）简介

17.1 SQLite：轻量级嵌入式数据库

17.2 SOCI库：C++数据库访问层

17.3 连接池设计

17.4 ORM框架（ODB）简介

17.5 本章小结