aspose file tools*
The moose likes Java in General and the fly likes Writing java object vs. xml in database Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Writing java object vs. xml in database" Watch "Writing java object vs. xml in database" New topic
Author

Writing java object vs. xml in database

Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
HI all,
I have come across a situation where I want to store something in database which could be loosely defined. In short, it would not be a flexible thing to create table/columns for that data as the data may vary.
Hence I thought of two possible solutions,
1. create a java object, serialize it and store it in the DB,
2. create xml like content (it doesn't have to be DTD based and all but just like using custom tags) and put it in the database.
I would appreciate any ideas on pros/cons that are associated with each of these options. Either way, we would not be able to query based on the column where we have put java/xml content but thats understandable.
Regards
Maulin
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12789
    
    5
If this was my problem I would go with XML just because it will be easier to make up test cases by editing text.
Bill
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I think its a question of granularity. I just encountered such a decision and I first tried to store a whole binary object in the db. But soon enough I realized that each change would force the whole object to be written.
I broke the object down into parts with a table so its not stored as binary. now only a column or two get updated as opposed to the whole object.
which do you want or which fits your design?
Stefan Wagner
Ranch Hand

Joined: Jun 02, 2003
Posts: 1923

If you want to query your entries WHERE col_foo LIKE '%bar%' , it would be better to store it in readable way.
Are there any restrictions - length of data, character set, ...


http://home.arcor.de/hirnstrom/bewerbung
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi CL and Stefan
I know exactly what you are talking about but in my case, as I mentioned in the post it would not be feasible to create tables to allow more flexibilty on my part you know. Okay, let me tell you what situation I am in,
- I have a DataSource which could be DB or LDAP
- I have to configure this Datasource for choosing where my field should get values from as list...
- Now, this datasource could be different for each fields I have. so I can say,
field1--> datasource1 that is <RDBMS,table,column>
field2--> datasource2 that is <LDAP,dtree node>
As we see here this level of configuration of RDBMS and LDAP could differ and even different LDAP sources might have to be configured differently as various LDAP servers etc support different auth mechanisms etc...So if I create tables then for LDAP and RDBMSs there would be different tables or some wiered logic you know...
And also, currently I cant put much time on that (as I am learning about a monster called J2EE which takes time) but again I can't ignore it as if my manager tomorrow tells me "does it support LDAP" I don't want to say, "its gonna take 1 week more" and I end up screwing my design dangerously...
you see my critical situation? Its like wife. One can't live with her NOR one can live without her
So essentially, my plan is to put XML as configuration for the datasource which will have type, params sort of structure and will have class for each type. Here, I would be able to add more classes for different types of datasource and interpret XML different for each of them you know.
I hope I don't sound complete Monkey
Regards
Maulin
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
also William, I agree with your point of view...
regards
maulin
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
unless the data already is in XML using XML as a datastore will yield a LOT of overhead.
OTOH serialization is not without pitfalls. If you ever change a class you previously serialized, reading the previously serialized data back can become impossible unless you specify your own serialization and deserialization routines in every class.
A third option you didn't mention might be to use an embedded DBMS inside your application to store the data. Something like hSQL or JDatastore would fit well (JDatastore has the added advantage of being an ODBMS so you can store entire objects and let JDatastore take care of versioning).


42
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi Jeroen
I agree about change in object after already written to DB. The XML I have is really small so I guess I am not running to lot of processing problems unless I get just so many requests for the data and processing might seem costly..
The third option suggested wouldn't work for me as I have to stuck to Oracle.
So far I am able to see some issues with either options...
Thanks guys...I will let you know sooooon , what I am going with...
Regards
Maulin
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

Well in my application I have one set of classes for storing in JET database, on set for MySQL, one set for storing to files, etc. Your going to have a set of classes no matter what format you choose. The choice is yours, none is better. If you do not need to discern information from the data, then perhaps a database is a bit much. That is, if you dont plan to use queries and its only a storing mechanism.
Jeroen Wenting
Ranch Hand

Joined: Oct 12, 2000
Posts: 5093
Depending on the version of Oracle, there is an Object relational wrapping layer or native XML database support.
You might be able to get the database to serialize your objects as XML for you, giving you the best (possibly) of both worlds
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Writing java object vs. xml in database