anonymous wrote : i was thinking that i could just expose a "clob" field on a single table and addtional info for that format could be stored as xml, but this may cause performance problems b/c of the un/marshalling that needs to be done. |
I strongly vote for this approach. Otherwise, as the module changes over time, you just get more and more tables and business logic. Drive it off a generic table structure + metadata about each news format. My data integration application has this architecture for dealing with different content types. I never have to change my database structures or my code to deal with new content types - configuration data only. I don't believe that performance will be that much of an issue, really. I have not found it so, and also look at things like Cocoon. anonymous wrote : there are going to be changes to the db schema, and i'm worried about having to deal w/ possible migration issues. what should our overall stance on schema changes be? As long as we are clear what has changed with regard to prior versions, then I don't see a problem with DB structure changes. You could even have a migration script - or someone could contribute one. This problem is one reason for doing the generic DB approach outlined above. Sherman View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3829960#3829960 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3829960 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
