次のように、C++ アプリケーションを他の C++ およびリモート Java アプリケーションと接続する必要があります。
1.C++ app --> 2.local sqlite Database --> 3.C++ sender --> 4.Java receiver
1.アプリはsqlite APIを使用して、スキーマを持つデータベースにデータを保存します。次のアプリ 3. そのスキーマを読み取り、thrift/rpc 形式に変換して、アプリ 4 に送信できるようにします。
私にとって、sqlite のスキーマと thrift/rpc 形式のスキーマを処理するのは苦痛です。データをsqliteではなく、データベースにjson形式で保存し、rpcメッセージングに同じ形式を使用することは可能ですか、それとも良い習慣ですか?
これは、保存しているものとアクセス方法に大きく依存します。アプリ (1) が一度にデータベース全体を書き込み、アプリ (2) が単純にすべてを読み取って送信する場合、データベースを sqlite に保存する理由はないかもしれません。大きな Thrift、Protobuf、または JSON BLOB として保存できます。おそらく、(3) と (4) の間で送信するために使用するのと同じ形式で保存して、変換が不要になるようにする必要があります。
しかし、アプリ (1) がデータベースを段階的に変更したり、後でデータベースの一部を読み戻したりする必要がある場合、またはアプリ (2) がデータベースで特定のキーを検索する必要がある場合は、sqlite を使い続けることをお勧めします。Thrift、Protobuf、および JSON はすべて、一度だけ書き込み可能な形式です。メッセージ全体を一度に書き込み、一度にすべてのメッセージを読み戻します。そのようなファイルをインプレースで更新することはできません。全体をメモリに読み込み、そこで変更してから、まったく新しいファイルを作成する必要があります。また、特定の行を効率的に検索することもできません。繰り返しますが、すべてを一度にメモリに読み込む必要があります。
しかし、はい、データベース ファイルを sqlite ではなく thrift/protobuf/json 形式で保存することは、ユース ケースに適合する場合は絶対に良い方法です。
ところで、別の可能性は、データベースを sqlite 形式で保存することですが、個々の行をそれ自体が Thrift、Protobuf、または JSON 形式の blob として保存することです。たとえば、データベースには主キーと "コンテンツ" BLOB の 2 つの列しかない場合があります。コンテンツ BLOB は、異なる形式でエンコードされたバイト BLOB であるため、スキーマ間で面倒な変換を行う必要はありません。このようにして、主キーでデータベースを検索できます。