What options exist for accessing different databases from C++?
Put differently, what alternatives are there to ADO?
What are the pros and cons?
Microsoft ODBC.
The MFC ODBC classes such as CDatabase.
OleDB (via COM).
And you can always go through the per-RDBMS native libraries (for example, the SQL Server native library)
DAO (don't).
3rd party ORM providers.
I would recommend going through ODBC or OleDB by default. Native libraries really restrict you, DAO is no fun, there aren't a lot of great 3rd-party ORM for C++/Windows.
Although this question and its answers are several years old, they are still valuable for people like me that cruise by on an evaluation trip. For this reason, I would like to add the Qt C++ framework's QtSql module as an option for database connectivity.
Note that I am familiar with Qt in general, but have no experience with QtSql in particular.
Pros (just a few that should also apply if you just choose Qt for its QtSql module): Qt is cross-platform. In my experience, Qt is well-designed, pretty intuitive to use, and extremely well documented. It has been around for a long time, is maintained by an active community and backed by Nokia, so it won't become unavailable over night. Since 2009, Qt has been licensed under the LGPL, so it is a real no-cost option even for commercial applications.
Cons: Qt is not small. You will introduce new types such as QString to your project. Qt is licenced under the LGPL, so you need to acknowledge its use even in commercial apps.
One thing - if speed is important and your code doesn't need to be portable, then it may be worth it to use the native libraries.
I don't know much about SQL Server, but I do know that the Oracle OCI calls are faster than using ODBC. But, they tie you to Oracle's version of SQL. It would make sense for SQL Server to be the same way.
There is the POCO Data library, which supports ODBC, MySQL and SQLite. Part of the free open source POCO C++ Libraries.
Related
Is there a standard set of integration tests for Mongo drivers (Connection Library)?
I have a Mongo library in C++ that I want to validate (and if possible performance test). Is there a standard set of tests (preferable with data) that I can use to validate that the library is sending and receiving the correct data to Mongo?
Is it a library or driver you are talking about?
"Driver Library"?
It provides the type to link to Mongo Server.
The types then provides methods to send/receive data etc.
And a few higher level concepts that I am experimenting with:
Handling all the on-wire protocol so that you don't need to.
You link against a library (So headers/library).
If you are developing a new C++ driver I hope you have some good reasons to not use the officially provided and maintained driver from MongoDB.
No; I don't have a good reason (other than I want to try).
But I do have reasons:
Experimenting with C++17 features that I have not used much.
I have a library that automatically serializes C++ objects to BSON with no extra code.
This seems like a perfect test project to validate it against.
I have a library that allows non-blocking use of streams that (with co-routines) allows me to write/read from multiple connections efficiently with a single thread.
This seems like a perfect test project to validate it against.
the officially provided and maintained driver from MongoDB
Sure the official one is going to have a lot more support and probably be much higher quality than my one-man band version. But you make that statement as if people should only use the official version of a library.
I disagree with that premise entirely as it locks us into the same way of thinking with no ability to have radical shifts in how we interact with the data. I want to experiment and see if I can have a more efficient interaction with the data and maybe (just maybe this will lead to the official version saying hey that's a nice idea let us implement that in the official drivers).
Competition is a way to spur new ideas (though we are probably a long way from competing).
But to get to that point I need a way to show that my driver behaves at least to a certain standard. Which means that it would be nice to have some way of validating. Here are a thousand JSON objects stream those to mongo and validate you get "XX" behavior or result.
The MongoDB C++ driver is developed open source and so are the tests to be found on GitHub:
https://github.com/mongodb/mongo-cxx-driver/tree/master/src/mongocxx/test
Your question could need some clarification:
Is it a library or driver you are talking about? If you are using the official MongoDB C++ Driver, why would you think it would send wrong results? Do you think your Library on top of the driver changes your values? Shouldn't be a test of the library independent of the driver be enough?
If you are developing a new C++ driver I hope you have some good reasons to not use the officially provided and maintained driver from MongoDB.
Lately I've been contemplating whether I should start studying another framework since I only have a windows machine and I don't intend to make cross-platform software anytime soon. So to help me with that decision...
Is there any disadvantage to using a cross-platform framework when I don't intend to develop cross-platform? Intuitively I would say that a framework specialized for a certain platform would perform better in said platform than a cross-platform framework. But I am just assuming that.
Please enumerate frameworks and libraries that I can start studying for rapid application development on Windows using C++. One with lots of documentation is preferred. I would appreciate it if you included a link that can help me get started.
Is there any disadvantage to using a cross-platform framework when I don't intend to develop cross-platform?
It depends on the framework. Most frameworks limit themselves to functionality which is available across all platforms, which may limit you somewhat. You may also not be able to take advantage of the best features of a given platform or the best development environment on that platform.
Please enumerate frameworks and libraries that I can start studying for rapid application development on Windows using C++.
A good option here is Qt. It provides a very nice C++ based framework for Windows and other platforms. If you want Windows only, there are other options, including the Windows Runtime via C++ (for Windows 8 development), or the Microsoft Foundation Classes.
By using a cross-platform framework, you will miss out on platform-specific frills, like programmatic control over Windows 7 Jump Lists. Because of these things, it won't quite feel like a native application, but like a port of an application written for another OS. In many cases this doesn't matter.
A modern C++ framework built using templates isn't going to perform any worse simply because it's cross-platform. You'll simply miss out on features that don't exist on multiple platforms.
Generally the issue with cross platform frameworks are framework specific.
e.g. wxWidgets - They are fast, but not too many GUI classes available. Documentation is not excellent however updated properly.
GNome - It is widely used but requires a heavy runtime deployment, bit more heavy in terms of memory usage.
These both are UI Frameworks. both are GPL and hence you can use it.
Nokia Qt - It is an excellent cross platform framework and it is not just yet another UI but a complete framework for cross platform development. However, problem with Qt is metaobjectcompiler (mod). It is a kind of language extension.
I would recommend that you opt QT as your next framework. It is being actively developed, lightweight, recently being open sourced and is available under LGPL lic.
Just to second the other answers, Qt is a great framework (and is hopefully going to survive Nokia).
Cross platform frameworks have mainly two disadvantages: performance (often they add another layer that is not necessary in native platforms) and of course being cross-platform, i.e. often not supporting functinality that is specific to your target platform. With Qt, I never saw performance as a problem. Also Qt brings in so many libraries that actually extend what you can do natively in Windows, that also the second point is not really a disadvantage here.
The only problem with Qt is in fact the metaobjectcompiler (moc). In the beginning, you will stumble across some strange compiler errors, that come in the end from the moc. Just remember this and google for the errors, you will get used to this.
I'm searching for a good C++ library for MySql, I read about MySQL++ and SQLAPI++, from your experience witch one should I use from this two or is there another library that you would recomand ?
Thank you.
A couple more to consider are SOCI and DTL. Most of the general purpose frameworks like Qt, Ultimate++, and wxWidgets include database access capabilities.
Mysql now distributes an official C++ library based on JDBC. I would use that unless there is some compelling reason not to(note there are plenty of those DB portability, licensing. )
what do you suggest as a cross platform "almost all encompassing" abstraction toolkit/library, not necessarily gui oriented?
the project should at some point include an extremely minimal web server and a "db" of some sort (basically to have indexes/btrees, maybe relations, so a rdbms is desiderable but avoidable if necessarily, sql might be overkill)
i was thinking about qt, boost, tokyo cabinet and/or sqlite; what else? what is "best suited"?
i would like to keep platform customization and overall execution footprint at minimum...
thank you in advance
For a minimal webserver, I think you're fine using Boost.Asio and sqlite -- it's quite portable, and should have everything you need. Remember that the C/C++ runtimes also provide portable abstractions for many things, so be sure to check those first (especially if a minimum overhead is required -- it might be simply easier to use C runtime functions than Boost.Filesystem).
You can also look at Firebird as a cross platform database
You should definitely take a look at Poco.
For my own similar purposes I use mongoose for web serving and sqlite for the database. Both are very high-quality products, but unfortunately are written in C. However, they are very simple to embed in C++ applications, and I have written simple C++ wrappers for both of them.
I am going to be using C/C++, and would like to know the best way to talk to a MySQL server. Should I use the library that comes with the server installation? Are they any good libraries I should consider other than the official one?
MySQL++
That depends a bit on what you want to do.
First, check out libraries that provide connectivity to more than on DBMS platform. For example, Qt makes it very easy to connect to MySQL, MS SQL Server and a bunch of others, and change the database driver (connection type) at runtime - with just a few lines of code.
MySQL-specific libraries are fine, but bear in mind that you are locking yourself down to one DB implementation - if you ever need to change in the future it's gonna be a whole lot of work - even if you design your code such that the DB-specific stuff is behind a facade. Why not use a library that provides connectivity to multiple platforms, and save yourself the trouble?
OTL is a solid cross-DBMS solution for C++ that my project has been using for years. We use it to talk to SQL Server (via ODBC) and Oracle (via OCI). It's fairly easy to drive, and comes with a large number of examples across all the supported databases.
There is nothing wrong with MySQL's own client-libraries. If you are willing to settle for reduced functionality, you can buy yourself some extra portability by using ODBC, UDBC, apr_dbd, or some other database-abstraction library (such as the OTL offered already).
This will make switching a back-end easier, but, as I mentioned, at the expense of offering less functionality compared to that of the native client. Because DB-vendors differ, the abstraction-libraries can only really offer the functions common to all (or most) of the back-ends. Whether you prefer to optimize for a particular DB or would rather make it easier to switch back-ends, is up to you (and, perhaps, your manager).