Back in October 2007, I wrote an article about PostgreSQL, C++ and the lack of binary data and wrappers.
I stand corrected. On two counts. The first is binary access. After looking through the
PostgreSQL API, I see that I can indeed get binary data into and out of a database easily. The C based library,
libpq, has an API call named PQexecParams which allows full separation of binary values from the query
statement. This is a good step towards preventing SQL injection attacks.
The second item upon which I stand corrected is a full binary C++ wrapper around PostgreSQL. I encountered
one today: SOCI - The C++ Database Access Library. It
handles Oracle, PostgreSQL, MYSQL, as well as a number of others. The library is templated and allows
extensions of user defined binary values.
If I'm not mistaken, it also provides a capability similar to what LINQ does in CLR languages, inlining of
SQL code. Or close enough that the difference does not matter.
While on the subject of databases, I'll make mention that, for a trading application in a Windows environment
that I've been developing, I've been starting to use the
HDF Group's HDF5 Database as a repository for historical
trade information. It handles custom binary record types, handles compression on the fly with a clever byte
pre-ordering strategy, with huge file sizes. I'll write more on it later once I've had a chance to break it in.
This is a C++ based library and works in Windows as well as Linux environments. I'm also going to try this
library out for managing SNMP based data from a custom network monitoring application.
SQL based engines are good for generic query applications, but when one wants a self contained application,
it is tough to get a user to install or allow installation of a separate engine. I suppose Microsoft's embedded
SQL engine is a counter example to that argument. But I was looking for something lighter in weight. For the
trading application I mentioned earlier, I've been trying out the
Berkeley DB C++
Library. It doesn't handle the overhead of SQL queries, but does all the low level table stuff, along with
transactions and secondary indexes. The code is a little more complicated, but it makes for a nice light weight
engine for storing queryable records. The HDF5 engine is good for storing large quantities of binary data, but
lacks a query mechanism. I think the division of labour between the two storage mechanism for a trading and a
network management application works well.