MFC programmers wanting to store data to disk have a couple of choices.
Although there are a variety of third-party options available, the choice generally comes down to a home-grown solution that includes code to access raw disk files, or using a major database server.
Home grown solutions can be anything from fprintf() to complex data-handling systems. By coding it yourself, you can add just the code you need and have it work exactly how you want. Of course, it can also be a lot of work, especially if you need something more sophisticated.
Major database servers make it easier to efficiently handle large amounts of data. And, using SQL (structured query language), you have a lot of flexibility in how your application can extract that data. However, this can complicate distribution and installation of your application if it requires access to a bunch of additional modules or perhaps even a database connection.
I was recently writing an application for a client and our needs seemed to fall somewhere between these two choices. We didn’t want the coding and distribution overhead associated with a complete database server, but we did want some flexibility on extracting the data in order to be able to produce a number of reports.
For this project, we decided to go with SQLite. SQLite is a complete SQL database engine but works quite different than those you may be familiar with. For starters, SQLite is completely free of charge. And, although this means no support, there are some forums you can access and I’ve found support there to be pretty good.
Second, the library comes as raw source code. Although you could compile it into a DLL and call the DLL, we simply included the source code in our project. They provide a combined source code so all we had to do was include the one file and a header file and we were good to go.
Of course, SQLite does not run as a separate process as a database server would. It is simply a library of subroutines in our application (which we developed a class library around). But we didn’t need a database server. And because the database is now part of our application, we don’t need to worry about distribution issues, installation problems, version incompatibilities, or anything else of that nature. And we have full SQL support when querying our data.
SQLite has a few oddities. The main one is that it does not enforce referential integrity. If you delete a row that is referenced by a foreign key in another table, you now have an invalid reference. It is possible to use triggers to catch this and perform, for example, a cascading delete. For our purposes, this hasn’t really been an issue.
Another thing is the way it stores data. You can specify a column to be an integer data type, but it doesn’t mean that’s how it will be stored. You can easily assign a string to a field in that column. It will correctly sort those strings based on their integer values. You just don’t know how the actual data will be stored. This has never been an issue for us either.
All in all, I think SQLite is totally cool. I now have all the power of SQL in a stand-alone application. And, being free, the price cannot be beat. You’d be surprised how many applications are using it as well. From desktop applications to cell phones, it contains thoroughly tested code. Depending on your needs, perhaps SQLite is appropriate for your next project too.