Where to keep the data in a simple .NET Windows app?

Imagine you have an app that manages some library and has its own data. The data has to be stored somewhere. Where should the data be stored?

I mean the following - are you going to install MySQL or SQL Server on the client machine? That seems like shooting flies with a cannon. Another way is to use something like SQLite, that does not require a running server, but it is a pain to use it (just my personal preference). There is also XML, but it is even more pain that using S开发者_运维百科QLite.

Where do you keep the data? Install SQL servers? Use own data formats? Any other ways?

I originally posted my thoughts as a comment because I'm not sure there is enough information provided on the type, quantity, and future needs of the data that you want to store. Not to mention I'm not much of a database expert, so one might take my advice with a grain of salt and use whatever you're ultimately most comfortable designing and maintaining.

That being said, I would never dream of using any kind of database for storing simple client data. The complexity and overhead seem unjustified, particularly when the advantages of a SQL database are all but lost on the type of application. If your data set can either be entirely loaded into RAM, or the performance impact of loading the data on demand from a saved file is negligible, you could do well to explore alternative options. The only scenarios where I would consider storage into a client-side database is if faster data retrieval times were absolutely required that could not be achieved through smarter/more efficient code design, or if the application could benefit from the indexing and searching capabilities that something like MySQL could offer.

Instead, I find that I naturally tend to structure data in trees. For any application where speed wasn't of the utmost priority or I wasn't dealing with particularly complex data types, I'd opt for XML serialization. Not only is querying and modifying an XML file considerably faster than a database with a reasonably small data set, the standard Microsoft DOM library makes working with XML data sources quite simple. Serializing instances of classes is built into the .NET Framework and makes me wish I'd had this functionality years ago when I spent all that time writing data storage and retrieval code. The other advantages of XML are that it can virtually eliminate versioning problems with future releases of your application, even if functionality is added, and that the data files can be viewed/edited by hand if necessary. Portability is also nice, allowing other programs to easily read and import your data, and if that happens, you don't run the risk of corrupting a database with multiple simultaneous read/writes. Finally, for what it's worth, I've found serializing custom data sets to XML files to be invaluable in debugging: I can save state and then open up the XML file to see exactly what data is stored.

In applications that XML doesn't quite fit the bill (normally because I'm trying to cheat and preserve the state of data-managing classes loaded into memory), I opt for binary serialization. This is also a great alternative to XML if you're looking for faster access times and the complexity of the data/data structure doesn't lend itself as naturally to XML's hierarchical format. This is also built right into the .NET Framework, and probably even simpler to set up than XML serialization (if that's possible). The two major drawbacks with this type of data storage are that seamless versioning becomes almost impossible and your data is stored in a proprietary format that is inaccessible by either the user or other applications. If versioning isn't an issue with your application, there probably isn't much to worry about here. However, with a couple of data management applications I've written, I've been bitten after going back and adding functionality later without taking precautions for reading data files created in previous versions.

Either way, with binary or XML serialization, I love the flexibility afforded to me as a developer with multiple, discrete files for documents. I can associate certain file extensions with my application in the shell, the user experience becomes vastly more intuitive for things like backing up, and users can easily exchange files created in my application with others who also have my application. How do you think Microsoft Word became so popular?

I've used XML in the past to manage simple data structures... worked out fine.

You can also store data using Settings

http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

If the data being stored was fairly simple, I would probably choose XML.

Otherwise, this would be a perfect use for SQL Server Compact Edition.

if the data is really simple, use Serialization

I'd vote for the SQLite database which you can keep in the home directory of the user.

I would go for db4o or SQL Server Compact Edition.

csv file? It has disadvantages but you don't need a to use a library to parse it. And it's fast.