By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,680 Members | 1,436 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,680 IT Pros & Developers. It's quick & easy.

Opinions Wanted: XML -vs- MDB (Jet)

P: n/a
I'm writing a smallish app to deal with scraping data from a website,
storing it locally and presenting some more meaningful stats about the data.

It has a need for roughly 6 tables and 3 "queries". Most of the tables only
need to store ~10-50 records. One table may have ~5000 records. The
"queries" would yield roughly ~5000 records.

I want to *easily* deploy this application to others hence the appeal of
just using XML as a datastore. The obvious problem is the need for
"queries". I can hand-write those queries in C# code or I could just use
the SQL capabilities of Jet.

MDB pros
1. Built-in query capability.
2. Better suited for evolving the application assuming new queries are
needed.

XML pros
1. Very simple install story.
2. Don't have to worry about MDB bloat.
Your thoughts? What thresholds (# of rows, install complexities, etc.)
would lead YOU to one or the other approach?

Thanks...
Jul 21 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
Kevin Brown wrote:
I can hand-write those queries in C# code or I could just use
the SQL capabilities of Jet.
You can also use the XPath query language, that is specifically designed
for XML.

MDB pros
1. Built-in query capability.
2. Better suited for evolving the application assuming new queries are
needed.
Also dependent on drivers and a threading model that are not well
adapted to multiuser use on the level of a public web site or service.

XML pros
1. Very simple install story.
2. Don't have to worry about MDB bloat.
Also not relational ( unless you write the joins as nested loops ).


Your thoughts? What thresholds (# of rows, install complexities, etc.)
would lead YOU to one or the other approach?
The key thing is the performance of XmlDocument.

Load one up with data that is roughly hetereogeneous to the degree that
your real data will be. Then do some xpath queries to check the speed.

Thanks...

--
An artist is someone who produces things that
people don't need to have but that he - for some
reason - thinks it would be a good idea to give them.
Andy Warhol
Jul 21 '05 #2

P: n/a
In this scenario, it may be that one vs. the other may end up being roughly
the same in speed, though you should check this. I think for most people SQL
is easier to work with then XPATH.

However, if you ever need to expand your app later, you may find it more and
more difficult to be writing code to query XML via XPATH, not to mention the
slowness will increase.

Another possible idea, is to read the XML into a dataset, and then do Select
on the datatables or put views on them to achieve filtering and sorting.

Lastly, if your queries involve joins, I think you will find it a lot more
difficult to achieve the correct result using XPATH then SQL.

"Kevin Brown" <no****@nospam.please> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
I'm writing a smallish app to deal with scraping data from a website,
storing it locally and presenting some more meaningful stats about the data.
It has a need for roughly 6 tables and 3 "queries". Most of the tables only need to store ~10-50 records. One table may have ~5000 records. The
"queries" would yield roughly ~5000 records.

I want to *easily* deploy this application to others hence the appeal of
just using XML as a datastore. The obvious problem is the need for
"queries". I can hand-write those queries in C# code or I could just use
the SQL capabilities of Jet.

MDB pros
1. Built-in query capability.
2. Better suited for evolving the application assuming new queries are
needed.

XML pros
1. Very simple install story.
2. Don't have to worry about MDB bloat.
Your thoughts? What thresholds (# of rows, install complexities, etc.)
would lead YOU to one or the other approach?

Thanks...

Jul 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.