Storing data with a stand-alone C++ application

Question

I work with Apache, PHP, and MySQL for web development and local applications. For the past couple of years I have slowly been learning C++ and want to build an application this summer. Specifically, I want to make a "library" application in which I can store information about the books, CDs, and records that I own. I know this type of app exists, but I want to learn C++ and this seems like a good way to go about it.

Here are a few questions:

1. Is it possible to create a stand-alone application that does not require a database for storing data?

2. If the answer to #1 above is "yes", is it a good idea to do this for an application that could potentially need to manage a lot of data?

3. What data-storage options would you recommend for use with a C++ application?

Thanks!

Update Well, there were a lot of good answers to this. This is such a great site with so many contributors. It turns out that I might not really need to go the C++ route for now. I now realize that I am most interested in writing an application that can function as a "library" organizational system more than I want to pursue C++. Thanks to everybody for your answers!

Answer 1

Is it possible to create a stand-alone application that does not require a database for storing data?

Yes, you could do some sort of custom file format for storing data.

If the answer to #1 above is "yes", is it a good idea to do this for an application that could potentially need to manage a lot of data?

It's not really a good idea, unless you really want to learn about storing data in a structured file.

What data-storage options would you recommend for use with a C++ application?

I'd look at SQLite. It is a database, but it doesn't need a separate engine.

Answer 2

If you don't want to use a database, you might want to save your data to a file (or maybe more than one). If so, the question is probably: which file format is the best? The answer depends on various factors:

1) Fast access, small size and easy to parse? The answer is "binary data". Just write your data directly as-is to the output file using fwrite. There are two downsides: the files are not human readable and it's cumbersome to maintain different versions. If the data you read isn't exactly what you expect, you run quickly into trouble.

2) Human-readable and easy to maintain? That's what XML is for. There are ready to use parsers like tinyXML which are excellent tools for writing data to file. The downside is that writing loading/saving routines takes more time (a lot is many cases).

3) Libraries that do the job for you. The MFC provides the CArchive class, but there are other and probably better tools to do this.

Answer 3

1. Yes.
2. It can be, but unless your needs are more specialized than they appear, a general purpose database manager is probably a better way to go.
3. For something like this, I'd think of using one of the (many) embeddable database managers that are available.

Given that you're (apparently) doing this primarily for self-education, not real use, it might make sense to write the code without a database manager to handle the storage. Writing all the code on your own will (with a bit of care) typically result in slightly higher speed, at the expense of quite a bit of extra work and usually some loss of flexibility. The biggest problem from a learning viewpoint is that quite a bit of what you learn doing this will only apply under fairly narrow circumstances (i.e., for most typical applications, you will want to use a database manager, so learning to do without rarely gains much).

A bit also depends on your intended use/audience. If you want to support more than one user at a time, things get much more difficult almost immediately (at least doing so efficiently). If you're only interested in one user being able to access the database at a time, that keeps things a lot simpler.

Answer 4

1. Yes
2. It depends on the data, "lots of data" is relative, you might find that the information about 1000 books can be stored in several MBs, then it would be an overkill to store that in a DB, unless it's a lightweight DB such as sqlite
3. I would recommend sticking to a plain text format such as CSV or XML.

For the sake of learning, it'd help you a lot NOT to use a DB engine, unless you want to learn SQL and relational DB design. On the other hand, using a DB engine is will make development faster and easier because because it'll create indices for different pieces of data to help you search easily and efficiently.

So it's up to you.

Answer 5

Hmmm...

Of course, you can do this.

What you're talking about doing is stepping back in time to the period before the RDBMS became successful. This isn't hard to do but you might well take some lessons learned:

1. Before you begin coding - or, at least, before you write data-access code, do your database design as if you were going to use a database - what data do you need? Can you reduce the number of attributes ("fields") you need? What are the commonalities among media types in your library? etc.
2. Consider use of directory trees and file names as a bit of an ad-hoc storage structure. This will put the data directly into the hands of command-line utilities, should you need or want to manage the data beyond your program's present abilities. For example, books might all be in a books subdirectory, and within that, you might use ISBN or title as the file name. I look for things that will naturally sort as a file name using ls, dir, or whatever your CLI uses.
3. Another good choice would be to put it in an XML format. Possibly both - use a directory hierarchy for the overall data layout and put the library entry data in flat files in an XML format. This could turn out to be handy at some point.
4. Put the data ONLY in plain text format as strings - no binary data! This is important, again, for being able to access / manipulate the data outside your program.
5. With such a strategy, you can use system tools like grep, sed, lex and so forth to do completely unplanned things with the data, should the need arise.
6. Have a feature - or write a separate reader program - that walks your "database" and outputs its entire contents as plain text, one line per entry. You might well have options that tell it what kind of media to output, etc. Also, include a flag that lets you set the delimiter used between attributes for output - comma separated is a common choice, but you might also just want a space, a carrage return, new line, or whatever else. If you make it an optional flag to let the user use anything and provide your favorite default, it should be fine.
7. Modularize your code so you can replace your storage strategy later if you so choose and not have to re-hack the whole program. You might even provide multiple storage strategies.

This ought to do it.

Note that the amount of data you will be managing, with modern computer hardware, is not likely to ever become a performance or space issue, so don't worry about saving a few bytes - it's not worth the hassle.

Good luck, and enjoy the ride.

Answer 6

I would also recommend SQLite.

From their web page:

"SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain."

"Think of SQLite not as a replacement for Oracle but as a replacement for fopen()"