Which option to select to use sql in C++ [closed]

Question

I want to connect and use sql database within my C++ application . My application need to store some data (can be stored in form of tables) which will be growing continuously and need to be shared between different processes - so I need a database. I selected sql because it is recommendable for beginners and I need multiple writer so no SQLite.

On searching I found following options (These options may include ORMS, APIs , and Drivers and may be some of these options shouldn't be even included - i.e I was totally wrong understanding that option; then please correct me):

1. SQLAPI++ - Source(ALSO OFFICIAL SITE)
2. MySQL Connector/C++ (Some advantages are also given there.) - Source
3. MySQL++
4. CppDB
5. SOCI
6. Libodbc++ (Runs on top of ODBC)
7. Database Template Library - Source
8. Oracle Template Library
9. Using sql.h with ODBC:
   Choices for ODBC:
   a. MYSQL Connector/ODBC
   b. EasySoft ODBC
   c. Some Others

Some SO's threads which help me to find these choices: T1,T2, T3, T4.

My Questions:

1. Which option to use and when? Advantages/Disadvantages of these options? (May be based on performance, learning curve, compatibility, present support.) Is there any benchmark or suggestion for selecting among these options. (I really don't know about these options, so may be some of these options required to group together to make them work i.e may be some of the options are inter-dependent.)
2. What are the required set of tools for these options.
3. If using any ODBC dependent library, then which ODBC to use. (There are many ODBCs mentioned in the link 'Some Others' above.)
4. Any source for learning them. (For some of the options I have already mentioned a source.)
5. Is there anything else that I have missed, entirely?
6. What if my application is in C? (This is because I also need to develop an application in C which uses sql)

I know I have asked too much. Please give suggestion for any particular part.

Answer 1

The main questions you need to consider are how cross-platform you need to be, both on the application, and the database side.

If you need to connect potentially to more than one relational database server (e.g. Oracle and MySQL or Firebird), you are likely to be better off using ODBC (for what it's worth I use UnixODBC). I haven't used SQLAPI++ or SOCI so I can't say much about how these compare to UnixODBC.

With UnixODBC, you get quite a lot of choice in deployment. Quite often, I don't actually install UnixODBC at all, and instead connect an application directly to the ODBC driver (this is useful if a particular instance is only going to be talking to a single database, and minimises the stuff you need to install). It also works with both C++ and C.

With UnixODBC -> MS SQL Server, we use the FreeTDS driver. Initially I was worried going into production with this, but in fact I found out the wire protocol is fully specified so this is more than a reverse engineered hack (and also I believe the same guys who make FreeTDS also do the commercial EasySoft drivers). MySQL provides UnixODBC compatible drivers themselves.

I haven't tried UnixODBC -> Oracle, as I had already written a direct OCI (instant client) interface and we have always used this.

UnixODBC is very slightly slower than using a wire-protocol approach like OCI, but the difference isn't significant enough to worry about. The reason we use OCI is that Oracle provide it free for Linux / AIX / Solaris platforms, while I couldn't find ODBC oracle drivers for these platforms.