Let me-reiterate. The point of this task is to get the schema to a stable state so we don't have to writing migration scripts every time we do a release. The columns I am considering removing are vestigial, they are not used in any joins. Also they more than likely negatively effect performance due to the extra unnecessary number of tables the database has to deal with. If someone wants to find out the actual jms destination they can join the channel id to the channel mapper table. If we're not going to remove them now, we will probably do so a few months down the line anyway, in which case we will have to write a migration script, and will have customers with a messy straggling database with some columns used, some columns not used. I.e. a support head ache. If everyone is using the same db schema then it makes a hell of a lot easier. If we make changes to the schema as I suggest this means we can support pretty much any message type without changing the format. So we have stability, performance, future proofing, clarity and conciseness. If someone really wants a normalised JMS specific database as Clebert would like, then they can create a JDBCPersistenceManager that does this. Yes, this will be as slow as a tortoise on crutches, but it's possible. IMO the default out of the box schema should be simple and performant and not contain redundant that seem to server no real purpose. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4011980#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...