Saving settings: XML or SQLite?

Question

I am currently writing an IRC client, and I was trying to find a good way to save the server settings. Basically a large list of networks and their servers, like most IRC clients.

I decided to use SQLite, but then I wanted to make the list available on the Internet in XML format (and, possibly, definitively), for other IRC applications. So now I can just save the settings locally in the same format.

I have very little experience with ADO.NET or XML, so I'm not sure how they will compare in this situation.

Is it easier to work with software? Is it faster? Does it matter?

Answer 1

This is a more vague question than you understand. "Settings" can include many things.

There is a good .NET framework for handling application settings in configuration files. They are typically exposed to your program as properties of a global settings object; classes in the System.Configuration namespace will take care of reading and saving them, and Visual Studio has tools that automatically generate code to work with them. One of the data types supported by this framework is StringCollection , so you can use this to store a list of servers.

But for a large list of servers, this is not my first choice for several reasons. I would expect that the elements in your list are actually tuples (e.g. hostname, port, description), and not simple strings, in which case you will have to format and parse the data to get it in a StringCollection , and this is usually a sign that you should be doing something else. In addition, the application’s settings are read-only (at least in Vista), and although you can customize the user area to be stable, it will lead you to a path that you probably want to understand before committing .

So, one more thing I would think: Is your server list just a list or do you have an internal object model representing it? In the latter case, I might consider using XML serialization to store and retrieve objects. (The only thing I saved in the application configuration file will be the path to the serialized object.) I would do this because serializing and deserializing simple objects in XML is very simple; You don’t need to design and test the correct serialization format, because the tools do it for you.

The main reason I look at using a database is because my program performs many operations whose results should be atomic and durable, or if for some reason I do not want all my data in memory at once. If every time X happens, I need a persistent record that leads me towards using the database. You do not want to use XML serialization for something like this, as a rule, because you cannot realistically serialize only one object if you save all your objects in one physical file. (Although it’s certainly not crazy to just serialize your entire object model in order to save one change. In fact, this is exactly what my company product does, and this points to another circumstance in which I would not use the database: if the data schema changes frequently).

Answer 2

I would personally use XML for settings - .NET is already created for this and, as such, has many built-in tools for storing your settings in XML configuration files.

If you want to use a custom schema (be it XML or a DB) to store the settings, I would say that either XML or SQLite will work just as well, since you have to use a decent API around the data warehouse.

Answer 3

Each tool has its own rights.

There is a lot of hype around XML, I know. But you should see that XML is basically an exchange format, not a storage format (unless you use a native XML database that gives you more options, but can also add some headaches).

When your configuration is pretty small (say, less than 10,000 entries), you can use XML and be fine. You will load all this into your memory and gain access to these records. Done.

But when your configuration is so large that you don’t want to download it completely, you rethink your division and stay with SQLite, which allows you to dynamically load those parts of the configuration you need.

You can also provide a small tool for creating an XML file from database content. Creating XML from a database is a fairly simple task.

Answer 4

It looks like you have two separate applications here: a web server and a desktop client (because that's traditionally where these things work), each of which has its own storage needs.

Server-side: Use a relational data store, not Xml. At some point, you need to save the user data separately from other user data on the server. XML is not a good repository for this.

On the client: it does not really matter. You will probably find it easier to manipulate Xml. And do not think that since you are using one technology in one setting, you must use it in another.