What is faster reading an XML file or querying a database

Question

I am designing a CMS in C# and need to decide where to save configuration settings for the site. Also considering defining my base html templates and then processing them server side to create the pages ahead of time.

So what is generally faster/less overhead for the server reading an XML file or querying that same information from a local database?

Answer 1

if your most important point is speed, then use a database. xml is very slow.

but, if your data is very "complicated" or has many different relations and attributes, consider using xml

Answer 2

Just for server settings - really doesn't matter. You're only going to read them once. Even if it takes a couple of seconds, still will be unnoticable.

First measure, then optimize.

Answer 3

How long is a piece of string? I can write a database query that's much slower than reading the same data from an XML file, but I can also write an XML file that's much slower to query than reading a database.

I would say if you're displaying "mostly" static content and you're worried about performance, then it's probably a better idea to implement it in whatever way you think would be the simplest, then use a caching mechanism to make it performant - this way, the first access might be "slow" but subsequent accesses will be much, much faster.

Typically, if you're generating HTML content, write the completed HTML to disk and send that to the browser, instead of populating it from the database/XML files on subsequent requests. If you have your backend process delete the cached files whenever it does an update to the content, then the server can automatically detect when the file doesn't exist and re-generate it again.

Answer 4

This depends on the strategy you are going to employ to access the data.

If you go the database route, are you going to cache your results? There could be a lot of network chatter if you constantly pull out the details from the db.

In terms of simplicity you really can be agnostic to the data source using Linq..

Faster? Once the stuff is in memory there should be no difference. Configuration information, as another poster pointed out is typically fairly static. Why not create a console app and quantify the differences, by using a profiler.

http://www.red-gate.com/products/ants_performance_profiler/index.htm?utm_source=google&utm_medium=cpc&utm_content=brand_aware&utm_campaign=antsperformanceprofiler&gclid=CLXmzbLXnKMCFQs-lAodSXTGsQ

Answer 5

It seems unlikely to me that this will be a bottleneck in your code. How often are you planning on reading configuration settings? Configuration is typically fairly small, and read infrequently. There are more important things to consider about where and how to store it:

• Bootstrapping: you can probably rely on your app having access to the local file system, and you can hard-code a configuration filename... but if all your configuration is in the database, where do you configure which database to talk to?

• Ease of tweaking and deployment: editing a configuration file on the server by hand may be faster than making a change in the database... but if you have multiple servers, do you want to tweak a file on every one of them?

• Simplicity of code reading/processing the configuration: what would your configuration look like? Is it naturally hierarchical? If so, XML is likely to be a good fit. If it's more like a set of name/value pairs, then a simple table is a good fit. Of course, you can store XML within a database - you don't have to tie the storage location and the storage format decisions together. Editing an XML document on the database may well be harder than either editing an XML file or changing individual values... but you can always make life easier with tools for this sort of thing.

Answer 6

I'd just use a database by default here. It's faster and requires less code.