开发者

Loading XML "Cache" Versus Querying DB. The Drawbacks?

开发者 https://www.devze.com 2023-02-02 07:36 出处:网络
For a read-only application, I am currently storing data开发者_运维百科 in a relational database, but rather than querying it via the app, I am doing a nightly write of the data, including its relatio

For a read-only application, I am currently storing data开发者_运维百科 in a relational database, but rather than querying it via the app, I am doing a nightly write of the data, including its relationships, to an XML file.

Granted, it is not a a lot of data -- the XML represents less than 1000 objects.

Then, through client side code, I am loading that data, and "querying" it as necessary.

No write opertations are required -- the app's sole function is search and display.

I've developed the app in such a way that whether it queries the db or the loaded xml can be switched very easily, and so I am able to compare performance.

I find that e.g. full text search (as such) is instant, etc, with the loaded XML approach.

However, I know there are drawbacks to this approach, and I would greatly appreciate it if any of you could help me flesh out when and why this is or is not a valid approach.

Thanks in advance.


When you load XML into a good XML processing engine, it constructs appropriate data structures to speed up XPath queries or the tree traversal in general.

When you keep the data in a relational database and query it, the query optimizer builds a query plan which will access data in some optimized way too.

Which method best suits you completely depends on the nature of your queries.

Note that loading an XML document and parsing it on each client call may be quite expensive, and unless you use some kind of an application server which keeps the parsed XML tree in memory, a database query will most probably be a better way since with 1000 records your whole table will fit into the cache.


It sounds valid to me.

The drawbacks would come if the size of the data was prohibitively large and threatened your available memory, or if it was shared in such a way that thread safety was an issue.

But you say it's small and read-only, so it sounds fine to me. Keeping the data close to where it's needed is something that every hardware designer would understand.

You say it's stored as XML, but I assume you read the file once per day, parse and store it in an in-memory DOM object, and query it using XPath. Is the XPath performance adequate for your needs? That would be my only concern.


It all comes down to resource management. If you have the resources to run queries it is a better road because your data is "live" vs. having an XML file that is cached and then parsing it. If you are worried about performance unless you are querying tens of millions of rows of data I wouldn't be too concerned. We have a box with about 60+ clients that constantly run queries all day and the box can actually perform quite well with everything running. XML parsing can be more stressful to the server than a query most of the time.

0

精彩评论

暂无评论...
验证码 换一张
取 消