XML or SQL Server?

[mrmagoo]

Hi. I'm writing a Windows Forms VB.Net app that is a recipe keeper. I am
starting to use SQL Server to hold the data, but I'm wondering if a database
is overkill. I might store a few thousand recipes maximum, so I'm wondering
if I should use XML instead.

My question is: is XML acceptible for this type of storage? The actions
performed include reading recipes, editing recipes and adding to them.
Deleting them, searching within them, etc.

There are 2 tables only, a Recipe table and Category table.

The fields used in the Recipe table are recipe name (varchar 100), recipe
description (text), date created, date modified, etc. The category table
includes categories used (Italian, etc).

It's a very simple database.

If I use XML, am I correct that I would have to load everything into
memory...into a dataset and then traverse through that?

If so, since I might have thousands of recipes, I might use a couple of
megabytes maximum of RAM, I would imagine. Is XML only memory-based? Is
there a way to grab only the bits of data I need as I need them?

The most important component of the product is the GUI. The fact that I need
a data storage mechanism is secondary. The front end, ease of use, is most
important, so I'm trying to figure out what is best for it. Is it acceptable
to load a couple of megs of data into memory for my application? Perhaps
that is not so much of an issue in 2006, where 512MB of ram is the new
minimum standard?

Any suggestions or advice would be great.

 

[Cor Ligthert [MVP]]

mrMagoo,

At this moment there is in my opinion aspecially with new application no
better alternative for SQLExpress. You have well described the problems with
XML, extra to that is that they can easily unwanted be deleted or wrong
versions overwritten, while with a write error you loose everything if you
don't protect that.

http://msdn.microsoft.com/vstudio/express/sql/download/

http://msdn2.microsoft.com/en-us/library/ms365247.aspx

I hope this helps,

Cor

 

[jeff]

A suggestion of sorts...design structure I guess...

Include at least to more tables ...
- Directions ... How to Cook the item.
- Ingredients...What is needed to cook the item...
So, this would give you three core tables...

Recipe Header
Recipe Directions
Recipe Ingredients...

This design would make your 'Header' table light wait - you would only
include 'lookup' and 'identification' information ... and allow users to
include as much detailed as they like without impacting search / lookup /
load performance.

I would recommend using a database of some sort ... it will be easier in the
end to maintain and upgrade. What happens when you change or add new
features to you applicaiton that require 'additional' fields in existing
tables or additional tables ... you will need to write an update procedure
that will update all the current xml documents to ensure they will load in
to the GUI ... however, with a database ... simple.

Also, have you considered using a MSAccess datafile for this ... XML files
are great for temporary storage but should not be used to 'replace' the
functionality of a database... As you build a relational data model ... you
need to be able to leverage the efficiencies and functional of a database
....even for simple 'two table' applications (because a two table application
can easily grow to 3, 4, 5, 10 tables ... and the technology you choose now
will impact your ability to scale the application later...).

 

[mrmagoo]

thanks for the input guys.