I’ve been yakking about how I’m working on a database access library, so maybe I should show you my current design to prove it. 😎 This should be the last of the dorky programming posts for a while.
The C++ standard library has nothing like the java.sql.stuff. There are some third-party libraries out there, but they seem kind of klunky to me, and I suspect that they don’t scale up to real world use cases. This makes C++ a really bad choice for use in the good old “business data processing” domain.*
I wanted a design that more closely matches common C++ idioms (container/iterator for example) so that coders wouldn’t have to learn a whole new way of thinking. It’s by no means an exact match (cursors are not really iterators, for example); but I think it’s the same general idea.
I’m not ready to share any code yet. Indeed, some of it might embarrass me. 😎 For a variety of reasons, it’s been a couple of years since I’ve worked on it; and I need to review some ODBC ugliness that I’ve forgotten to finish the SQL/CLI implementation. I haven’t even started on the Web client business which needs to be part of the proof of concept since I claim that I can make it work.
If there’s anybody out there who thinks this is basically a good design and would like to run with it themselves, I’ll happily share what I’ve got so far (probably about 1500 lines of code, not really a big deal yet). I’m currently stuck on conversions between C++ and SQL types, which is central to making cursors work and depends on some ODBC stuff that I can’t remember.
My goal of getting WG21 to publish this in a TS will probably never be realized, but I think it’s worth doing anyway. I’ll implement the rational number that I mentioned in the previous post first just to have some fun and get back in the groove; then I’ll see whether I can restart the work on the database library.**
*Business data processing will probably never be more than a niche market for C++, but that’s where the bulk of my experience is and so it’s what I know most about.
**My local PBS affiliate is starting up its quarterly pledge fortnight, so I shouldn’t have much TV to watch for a couple of weeks. 😎
Personally I’m a big fan of using straight-up sqlite. Not having uses C++ in decades, I don’t know how good the interface is there. But in Python queries tend to return tuples or lists so I generally don’t bother with ORM tools.
I’m not proposing something for having fun at home. In my day job, when I had one, queries might sometimes return a few hundred thousand rows of fifty or more columns and I had to do some arithmetic or other processing on them — or maybe I needed to load some normalized tables with data from some huge flat file — things like that. In my experience, quickie tools don’t scale up.
I think you need to read up on sqlite.
It’s widely deployed. For example in your smartphone and your browser. You can read/write small blobs from/to an sqlite database faster than from a native filesystem.
There are reports of people using 1 TB sqlite databases.
@3:
sqlite is extremely nice in the niches it serves well. (However like any project, there are going to be instances of overhyping by its fans.)
No blue chip is ever going to use it to run payroll.
If your answer to a genericised language wrapper around any SQL database is “everyone should just use database X and use X’s native API” then you really have no business commenting on the subject, and the choice of X is immaterial.
I hadn’t heard of SQLite so I Googled for it. On the very first page I found:
End of discussion. 😎