When I was working as a website designer/engineer I primarily used databases for storage of much of my dynamic data. It was very easy and convenient to use this method and seemed like a standard practice from my research on the matter. I'm now working on shifting away from websites and into desktop applications. What are the best practices for data storage for desktop applications? I ask because I have noticed that most programs I use on a personal level don't appear to use a database for data storage unless its embedded in the program.

I'm not thinking of an application like a word processor where it makes sense to have data stored in individual files as defined by the user. Rather I'm thinking of something more along the lines of a calendar application which would need to store dates and event info and such where accessing that information would be much easier if stored in a database... at least as far as my experience would indicate.

  • 1
    Are the only two options for data storage either a file structure of some sore or a database? Or are there other best-practice methods of data storage?
    – Kenneth
    Commented Mar 6, 2011 at 1:47
  • If you're storing data, it ends up in a file somewhere (unless you're doing something exotic like using raw disk partitions). That somewhere might be on another machine. It might be managed by some kind of DB engine (of which there are many types). Commented Jan 25, 2012 at 22:57

2 Answers 2


SQLite or other embedded databases are common for client applications. XML/Registry for settings (in Windows). Server applications use full database engines just like web applications but MySQL is less common.

This is a generalization - there are many storage possibilities.

  • 2
    +1 on SQLite. It's what many iPhone and Android apps use, and is a very lightweight and usable DB.
    – Peter K.
    Commented Mar 6, 2011 at 2:16

Data can be stored in many formats. The relational database approach is one of them of course. However, some vendors may want to stay away for ODBC settings and OLEDB problems as well as connectivity issues with regular relational databases. Some vendors opt to use their own 'databases' systems (some of those are based on Indexed Sequential Access Method ISAM Wiki-ISAM).

Some applications use direct-files and some may opt to use sequential (csv or otherwise)/binary files. Since most personal applications have small number of data rows, it is easy to read the entire data in memory and use arrays, LINQ, DotNet ADO, and many like methods to access the data in memory.

The best practice depends on many factors such as your programming language, need to protect the schema, need to protect the data, logging, transaction rollback, etc. For example, using a relational database on the client would expose your schema which is something you may not want to do. On the other hand, if you use a sequential file, you may not be able to use a reporting tool directly.

I would prefer a relational database if you could live with the drawbacks such as exposing data and exposing schema to end user.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.