I think that for a performance and scalability standpoint that way will cause issues.
#You cant be transacted across multiple threads. See my previous post. I mentioned oracle but I think MySql will to the same thing. My point is that schema alters are a terrible thing to do to a production database.
#Since you're changing the schema on the fly, you're going to have to change your jdbc insert/update/alter on the fly. You're going to have to find a way to synchronize your jdbc calls if you're inserting/updating and altering.
#If you're having a user append a column, and you have 10M records guess what, you're allocating space for 10M records for with null or worse, updating all 10M records with redundant values. First case being a waste of disk space, second case being a bigger waste of disk space and will take forever to execute.
My suggestion is to break out into a couple of tables.
Issues table.
Issues attributes type table
A join table in between with
Index properly and if needed, use database hints. Even better, have the database do the work for you by creating database functions or stored procedures. Tweak your JDBC driver for performance. Profile the heck out of your query and if performance is still an issue, dont use JPA. EBAY from what I understand, still uses JDBC in parts of its application
[Message sent by forum member 'fdlcruz' (fdlcruz)]
http://forums.java.net/jive/thread.jspa?messageID=219991