不要重新发明这个轮子。
它已经重复地完成了,虽然最流行的系统 ( ODBC ) 无疑是丑陋的,但它已经为您听说过的每个数据库编写了抽象。通过UnixODBC项目,它也存在于 UNIX 和 POSIX UNIX 上,例如 Mac OS X。
libdbi是一个不那么丑陋但支持更窄数据库的替代方案。您不会像 ODBC 那样从供应商那里获得 libdbi 的驱动程序。
怎么反复?
如果 C++ 没问题,我听说过的另一个很好的数据库抽象层是诺基亚(曾经是 TrollTech)提供的Qt 框架的 数据库接口。它的主要优点是已经*编写*和测试过。主要的缺点是,如果您的应用程序核心不是基于 C++ 和 Qt 的,它会有点笨拙。
其他 C++ 选项(我没有亲自使用过)是sqlapi++、dtemplatelib和SOCI。
如果此时您想知道为什么所有这些数据库抽象层都是为 C++ 编写的,也许这是一个提示。如果你用 C 编写一个 DB 抽象层,我敢打赌你会通过函数指针的结构重新发明 C++ 虚方法,并且最终可能会创建几乎和GObject一样丑陋的东西,在这种情况下,你不妨使用libgdb / gnome -分贝。为了避免虚假虚拟方法垃圾,您可以通过运行时库路径在链接时选择您的 DB 层,并只提供一堆普通的旧函数,但我不知道为什么当有这么多现有函数时你会这样做选项就在身边。
顺便说一句,如果事实证明您根本不需要 DB 抽象,只需要一个更好的接口(因为您主要针对 Pg),请查看libpqtypes(纯 C,没有 C++,非常便携),也称为“什么libpq 应该是”。即使您要添加一个抽象层,也可能值得在 libpqtypes 上进行,而不仅仅是 libpq。
如果 ODBC、libdbi、libpqtypes、Qt 等不适合您,您需要定义原因,并创建一组更具体的标准来满足。
或者:如果您的设计允许,您可能需要考虑使用具有 DB 抽象层(如Python ( psycopg )、Ruby、Perl或Java ( JDBC ))的嵌入式高级语言进行数据库访问和相关工作。所有这些都有自己被广泛采用和经过良好测试的数据库抽象层,您可以从中受益,同时仍然用 C 编写大部分程序。或者,就此而言,您可以只用 C 编写程序的性能关键部分作为库并从您选择的语言中使用它,并使用已经为您编写的健全的数据库抽象层。
数据库抽象很难。真的很难。数据库抽象使用起来并不可怕,性能不错,并且足够灵活以使用数据库,因为比愚蠢的行存储更难 - 迟早,你需要的不仅仅是一个愚蠢的行存储。