You may find it useful to read this:
Data Access Object (DAO) versus Object Relational Mapping (ORM)
http://www.codefutures.com/weblog/andygrove/archives/2005/02/data_access_obj.html If you have 200 tables, then you may be better off just generating your data persistence tier rather than manually doing 200 mappings.
The advantage of generating the persistence code rather than using a graphical mapping tool (or even writing XML mappings) is that you can simply regenrate in a few seconds if you make changes to the database schema.
With regard to the choices:
-JDBC DAOs - Data Access Objects are a core
J2EE design
pattern - so it's a sound approach (provided you're not hand-writing the DAOs!). The most simple solution with the shortest learning curve. No runtime/deployment fees.
-EJB CMP - often must be used in projects because everything has to be written for a J2EE app server. Not so bad if you're generating the code. Most J2EE products have runtime/deployment fees.
-JDO - the best data persistence specification. Problems with politics - even if the JCP vote on JDO 2.0 goes well, the specification has been damaged (which was the intention of the J2EE vendors that voted against it, I suppose). Using mapping tools for 200 tables would be a bit of a drag - but JDO is ideal for code generation so you can have your JDO code in a few seconds. Some JDO implementations have runtime/deployment fees.
-Hibernate - without doubt where the market momemtum is. Remember this is a proprietary product - but you get the source code so you'll never really be stuck. No runtime/deployment fees.
I should point out that CodeFutures supports all off the 4 options above so we're pretty neutral regarding the data persistence strategy.
PJ Murray
CodeFutures Software