C++でのデータベースインターフェイスの開発を開始するのに最適なポイントは？

Question

私は現在、いくつかのサーバー/クライアントベースのアプリケーションで作業しています。 アプリケーションはマルチスレッドであり、プラグインをサポートしています（dlopen、...経由）。複数のデータベースで動作する必要があります。

今、DBI-ABCの設計を開始するためのヒントを探しています。まず、私はこのような簡単なインターフェースを考えました：

typedef struct { 
    unsigned int userid; 
    std::string username; 
    std::string fullname; 
    unsigned int usermodes; 
} user_row_t; 

class AbstractDBI 
{ 
public: 
    virtual ~AbstractDBI() {}; 

    virtual bool getUserData(int userid,user_row_t &row) const = 0; 
    virtual bool setUserData(user_row_t &row) const = 0; 
    // ... 
} 

このデザインは、アプリケーションコアで使用されるすべてのステートメントを処理するのに十分です。しかし、ユーザーが書いたプラグインでデータベースへのアクセスが必要な場合は、DBIクラスに触れなければなりません。

アプリケーションの負荷が高くなるため、準備されたステートメントは必須です。また、postgresにはデータベース固有のデータ型、たとえばinetを使用します。

誰もがこのようなことをしてくれたことがありますか？

Answer 1

私はこのようなものを設計したことはありませんでしたが、前に使用した例はデータベースレコードが本質的にstd::map<std::string, boost::any>の構造体に格納されていて、 boost::anyとは異なります。 DBに対してSQLクエリを実行することができます。これらのジェネリック構造の1つに、要求したフィールドが返されます。

これを基本クラスに入れると、DB固有の詳細を処理する具体的なクラスを導き出すことができます。これにより、いつでもDBをスワップしてプラグインに柔軟性を持たせることができます。

プラグインを完全に自由にしたくない場合は、制限付きのユーザーにアクセス権を与えることができます。

Answer 2

これはStrategy Patternのシナリオのようです。ストラテジオブジェクトの特定のデータを取得するクエリをラップすることができます。その後、一連のデフォルト戦略を提供できますが、クライアントはDBMS固有のものを使用する独自の戦略を提供したり、異なるスキーマを使用することができます。