我需要用 C 语言为 PostgreSQL 的数据库访问 API (libpq) 和其他一些关系数据库管理系统编写一个数据库抽象层。
我正在考虑在 pqsql 和其他可能的数据库系统中编写自己的现有函数抽象。 编写此类数据库抽象 API 时应考虑的最佳策略是什么？
到目前为止，我首选的写作计划可能是:
- 为任何特定数据库定义 header 、函数和包装器 感兴趣的系统。
- 当使用第一个连接调用(函数)时，检查并确定它适用于哪个关系数据库管理系统。
- 包括一组正确的数据库抽象方法和定义。
但这种处理方式可能仅一次允许使用一个关系数据库管理系统。这对于数据库抽象层来说很常见吗？
可以考虑哪些其他选项？
最佳答案
不要重新发明这个轮子。
它已经重复地完成了，虽然最受欢迎的系统 ( ODBC ) 无疑是丑陋的，但它已经为您听说过的每个数据库编写了抽象。 随着UnixODBC项目它也存在于 UNIX 和类似 POSIX UNIX 的系统上，例如 Mac OS X。
一个不那么难看但支持范围更窄的数据库的选择是 libdbi .您不会像为 ODBC 那样从供应商处为 libdbi 获得驱动程序。
如何重复？
如果 C++ 没问题，我听说过的另一个 DB 抽象层是 Nokia(曾经是 TrollTech)提供的，Qt framework's database interface .它的主要优点是已经*编写*和测试。主要缺点是，如果您的应用程序核心不是基于 C++ 和 Qt，它会有点笨拙。
其他 C++ 选项，我个人没有使用过的，是 sqlapi++ , dtemplatelib和 SOCI .
如果此时您想知道为什么所有这些数据库抽象层都是为 C++ 编写并用 C++ 编写的，也许这是一个提示。如果你用 C 编写一个 DB 抽象层，我敢打赌你会通过函数指针的结构来重新发明 C++ 虚拟方法，并且可能最终创建出几乎和 GObject 一样丑陋的东西。 ，在这种情况下，您不妨使用 libgdb / gnome-db .为了避免伪造的虚拟方法垃圾，您可以通过运行时库路径在链接时选择您的 DB 层，并只提供一堆普通的旧函数，但我不知道你为什么要在这么多现有的情况下这样做选项就在附近。
顺便说一句，如果事实证明您根本不需要 DB 抽象，只需要一个更好的接口(interface)(因为您主要针对 Pg)，请查看 libpqtypes (纯 C，没有 C++，非常便携)，也被称为“libpq 应该是什么”。即使您要添加一个抽象层，也可能值得在 libpqtypes 而不仅仅是 libpq 上进行。
如果 ODBC、libdbi、libpqtypes、Qt 等不适合您，您需要定义原因，并创建一组更具体的标准来满足。
或者:如果您的设计允许，您可能需要考虑使用具有数据库抽象层的嵌入式高级语言(如 Python)来完成数据库访问和相关工作。 ( psycopg ), Ruby , Perl , 或 Java (JDBC)。所有这些都有自己广泛采用和经过良好测试的数据库抽象层，您可以从中受益，同时仍然用 C 编写大部分程序。或者，就此而言，您可以只用 C 编写程序的性能关键部分作为库，并使用已经为您编写的健全的数据库抽象层，以您选择的语言使用它。
数据库抽象很难。真的很难。数据库抽象使用起来并不可怕，性能良好，并且足够灵活以使用数据库，因为比哑行存储更难——迟早，你需要的不仅仅是哑行存储。
关于c - 用 C 编写数据库抽象层的好策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10204925/