tags:

views:

1264

answers:

7

I'm just learning C++, just started to mess around with QT, and I am sitting here wondering how most applications save data? Is there an industry standard? Do they store it in a XML file, text file, SQLite? What about sensitive data that say accounting software would need to save? I'm just interested in learning what the best practices for this are.

Thanks

A: 

Do they store it in a XML file, text file, SQLite?

Yes.
Also, Binary files and relational databases.
Anything else?

shoosh
You can still be nice when answering.
Joe
+7  A: 

This question is way too broad. The only answer is it depends on the nature of the particular application and the data, and whether or not it is written in C++ has very little to do with it.

For example, user-configurable application settings are often stored in text files, but on Windows they are typically stored in the Registry. Accounting application typically keep their data in a database of some sort.

Dima
+3  A: 

There are many good ways to store application data (call it serialization).

Personally, I think for larger datasets, using an open format is much, much easier for debugging. If you go with XML, for example, you can store your data in an open form so that if you have file corruption issues (i.e. a client can't open your file for some reason), it's easier to find. If you have sensitive data in there, you can always encrypt it before writing it to file using key encryption. Microsoft, for instance, has gone from using a proprietary format to open xml in their office docs. They use .*x extension (.docx, .xlsx, etc). It's really just a compressed folder with xml files.

Using binary serialization is, of course, the industry standard at the moment for most standalone applications. Most likely that is because of the application framework they are using (such as MFC, which is old). If you take a look at most of the serialization techniques in modern application frameworks, XML serialization is very well supported.

Mike Caron
+1  A: 

There is no standard practice, however if you want to use complex structured data, consider using an embedded database engine such as SQLite or Metakit, or Berkeley DB files. XML files would also do the job and be human readable/writable. Preferences can use INI files or the Windows registry, and so on. In short, it really depends on your usage pattern.

fbonnet
+2  A: 

First you need to clarify what kind of data you would like to save.

If you just want to save some application settings, use QSettings to save your settings to an INI file or registry.

If it is much more than just some application settings, go for XML files or SQL.

corné
+1  A: 

This is a general question. Like many things, the right answer depends on your application and its needs.

  • Most desktop applications save end-user data to a file (think Word and Excel). The format is up to you, XML, binary, etc. And if you can serialize/deserialize objects to file it will probably make your life easier.
  • Internal application data such as configuration files or temporary data might be saved to an XML file or an lightweight, local database such as SQLite
  • Often, "enterprise" applications used internally by a business will save their data to a back-end database such as SQL Server or Oracle. This is so all of the enterprise's data is saved to a single central location. And then it is available for reporting, etc.

For accounting software, you would need to consider the business domain and end users. For example, if the software is to be sold to large businesses you would probably use some form of a database to save data. Otherwise a binary file would be fine, perhaps with some form of encryption if you are really paranoid.

Justin Ethier
+1  A: 

When you say "the best way", then you have to define what you mean by "good".

The problem is that various requirements conflict with each other, therefore so you can't satisfy all of them simultaneously.

For example, if one requirement is "concurrent multi-user access to the data" then this suggests using a database engine, but that conflicts with "as small as possible" and "minimize dependencies on 3rd-party software".

If a requirement is "portable data format" then this suggests XML, but that conflicts with "compact" and "indexed".

ChrisW