Which data store for a management service like IIS

Question

I have a C# Windows service which manages some stuff for my server application. This is not the main application, but a helper process used to control my actual application. The user connects to this application via WCF using a WinForms application. It all looks a bit like the IIS manager.

I need a data store for this application.

Currently, I use separate XML files which are loaded at start up, are updated in memory and flushed to disk on every change. I like this because:

We can simply edit the XML files in notepad when issues arise;
I do not have external dependencies to e.g. MSSQL express;
I do not have to update a database schema when the format changes.

However, I find that this is not stable and that the in memory management is very fragile.

What should I use instead that is not overkill (like e.g. MSSQL express would be) without loosing too many of the above advantages?

What part of this isn't stable? What errors are you getting? What kind of memory management issues are you having? — RQDQ, Apr 08 '11 at 15:39
Your XML file should do what you are asking just fine. What is that is "not stable" and "fragile" about it? I would look to refining your IO rather than looking for a new technique. — Cos Callis, Apr 08 '11 at 15:40
Have you looked at SQL Server Compact, sounds like a good idea in your case, only downside is schema changes but honestly how often does this happen and how complex are the changes, maybe look at EF code first to update your schema everytime something changes (Will most likely lose data though) — TBohnen.jnr, Apr 08 '11 at 15:40
I have the most problem managing the different files. I have tried using a single global `lock`, but that is too course and moving to a more fine grained model makes this part of the application too complex. (I feel I'm building a database, and that's not good.) — Pieter van Ginkel, Apr 08 '11 at 15:57

score 1 · Accepted Answer · edited Jun 20 '20 at 09:12

1

SQLite is made for occasions like this where you need a solid data store, but do not require the power or scalability of a full database server.

If you do not want to worry about schema changes, you may be best off with your xml method or some variety of NoSQL database. What exactly is unstable about your xml setup?

If you have multiple concurrent processes accessing the xml file, you will have to load it quite often to ensure it remains synchronized. If this is a multiuser situation, xml files may not be feasible past a very very small scale. This is the problem database systems solve fairly effectively.

edited Jun 20 '20 at 09:12

Community

1
1

answered Apr 08 '11 at 15:39

captncraig

22,118
17
108
151

I have the most problem managing the different files. I have tried using a single global lock, but that is too course and moving to a more fine grained model makes this part of the application too complex. (I feel I'm building a database, and that's not good.) I was thinking of NoSQL too, but I would love a suggestion for my situation that is .NET native without having to install an extra server. – Pieter van Ginkel Apr 08 '11 at 16:07
I'd recommend checking out RavenDB (http://ravendb.net). I haven't used it personally, but I know it is fairly mature, and pretty easy to use in .NET – captncraig Apr 08 '11 at 17:13

score 1 · Answer 2 · answered Apr 08 '11 at 15:39

1

Try SQL CE or SQLLite.

answered Apr 08 '11 at 15:39

BrandonZeider

8,014
2
23
20

score 0 · Answer 3 · answered Apr 08 '11 at 15:42

0

db4o

One solution would be to use and object database like dB4o. It has an extremely small footprint, is fast as hell and can you can add properties to your persisted objects without needing to make schema changes. Also, you don't have to write any sql.

Storing objects is as easy as:

using(IObjectContainer db = Db4oEmbedded.OpenFile(YapFileName))
{
   Pilot pilot1 = new Pilot("Michael Schumacher", 100);
   db.Store(pilot1);
}

XML in Database

Another way to do it is using something like SQLLite or SQL CE (as mentioned by other posters) in conjunction with xml data.

Data Contract Serializer

If you're not already using the DataContractSerializer / DataContracts to generate / load your xml files, it's worth considering. It's the same robust framework that you're already using for WCF. It handles versioning pretty well. You could use this to deal with xml files on disk, or use it with a database.

answered Apr 08 '11 at 15:42

RQDQ

15,461
2
32
59

What do you mean by the combination of XML and SQLite? I was thinking about creating a database structure that could store the XML nodes and attributes as records. What do you think? – Pieter van Ginkel Apr 08 '11 at 16:00
@Pieter - I was thinking more along the lines of just blasting the xml into the database as one big string. Just about any embeddable database out there supports some sort of large text field / memo field, etc. If you try to shred the nodes and attributes into a relational structure, you'll suffer performance and complexity problems. – RQDQ Apr 08 '11 at 16:28
Performance is not a problem because there is very little data (~30 XML files, 600 elements/attributes in total). Complexity, maybe. With the XML blobs, I would still need a way to index the data which would mean I need a normalized schema and I'm back at SQLite. – Pieter van Ginkel Apr 08 '11 at 16:54
There are some other choices... How about a NoSQL embedded approach. ESENT is built into Windows. RavenDB might work as well. This question has more answers: http://stackoverflow.com/questions/2081080/embedded-non-relational-nosql-data-store – RQDQ Apr 08 '11 at 16:57

Which data store for a management service like IIS

3 Answers3