• Post Reply Bookmark Topic Watch Topic
  • New Topic

Any better approach? Instead of converting criteria to XML and XML to blob  RSS feed

 
Punit Jain
Ranch Hand
Posts: 1085
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

Please Help me to find a better approach.

Currently we save the searches with following approach -

we create xml with the criteria user entered, and then convert this XML to blob to save into database.
now to get those saved searches, we read them from database as blob, convert them into XML and store them in buffer and from buffer we render them on the UI.

But currently we are in position to change this slightly if there is any better approach.

We use XML because we allow users to export and import saved searches.


My observations -

when we convert XML to blob and save into database, we unnecessary save lots of data because of XML tags.

Is there any better/more performant approach for doing this?


Thanks,
Punit
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
we unnecessary save lots of data because of XML tags.

What is the ratio of overall stored data size to the functional data size? Unless it's significantly above 1 (in which case you may want to restructure the XML), it's probably not worth worrying about much. I probably wouldn't store XML in the DB, though, but rather use a structured table for that. It's easy enough to create any desired output format from that, like XML or JSON.

Is there any better/more performant approach for doing this?

Is performance really an issue? I can't picture the involved amounts of data being so large that any other approach would result in a humanly noticeable difference.
 
Punit Jain
Ranch Hand
Posts: 1085
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for replying Ulf.

Ulf Dittmer wrote:
we unnecessary save lots of data because of XML tags.

What is the ratio of overall stored data size to the functional data size?

do you mean by comparing the data generated by tags to the data generated by tag values (actual data)? if yes what is the correct way to calculate this?

Ulf Dittmer wrote:
Is there any better/more performant approach for doing this?

Is performance really an issue? I can't picture the involved amounts of data being so large that any other approach would result in a humanly noticeable difference.


well, why i thought about performance is because, on the UI we show only 15 search histories, but still it takes some milliseconds to render. however i am not sure if it is expected time or not. but my observations are rendering 15 search histories should not take even milliseconds. or may be for this i should think about the rendering part not the db and all stuff?

by the way, here s sample XML -




Above XML is with some basic criteria, however mostly searches has so many criteria.
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if yes what is the correct way to calculate this?

There is no "correct" way - just compare the overall size to the actual size of the data being stored. The XML you showed in indeed very "wordy", but given what it's used for it's highly unlikely that that makes a difference in terms of either speed or size.

it takes some milliseconds to render. however i am not sure if it is expected time or not. but my observations are rendering 15 search histories should not take even milliseconds.

Expected by whom according to what? What observations have you made? When using an application, a human being won't notice the difference between 5ms and 50ms, so this seems to be a case of premature optimization. See http://stackoverflow.com/questions/536300/what-is-the-shortest-perceivable-application-response-delay
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13078
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are really worried about the volume of text in an XML document, XML responds very well to compression since the tags repeat so much.

Bill
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Punit Jain wrote:well, why i thought about performance is because, on the UI we show only 15 search histories, but still it takes some milliseconds to render. however i am not sure if it is expected time or not.

Then you need to find out. What Ulf is basically saying is that there is rarely any correlation between "best" and "fastest", unless speed is the ONLY criterium you use to decide how "good" something is - and that's generally a poor way to go.

The only thing that occurred to me is that if your database has a CLOB, as opposed to a BLOB, I think I might favour using that, since XML is basically text.

Obviously, if you take William's (very good) advice and compress it first, you're back to a BLOB, but you might want to check if your db does any form of compression of its own first.

Winston
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!