I have been reading both polemical articles of David Jordan and Donald Bales.
Both technologies of Object-Relational mapping are relative new to me so I readed the articles carefully.
Personally my conclusion is that both technologies have their advantages and disadvantages and is the designer who has to decide which one is the best alternative for the problem to be resolved.
I'll post what I think that are the advantages and disadvantages so you can correct me if I'm wrong.
Database O/R Mapping:
Bales, this alternative enlighted me first time so I run to try your example but the consecuences but with I get frustrated. I'll tried to run your example in DB2, MySQL and PostgresSQL and or the driver doesn't support type mapping or simply the database doesn't support that part of the SQL99 estandar. So my conclusion is:
- Having the object mapping directly in your database. You can work directly with objects which makes the logic of your application easier to design and understand.
- Solution independent of the language so your object wrappers will be mostly the same independently of the language choice.
- More performance than with an Object Oriented Database solution. No need to load innecesarilly complex and expensive hierarchies of objects when you only want to get a simple field. Correct me if I'm wrong here I'm not a expert in object databases, but recently i read in JDJ that an hybrid approach has the best performance.
- As David and Donald said with JDBC+SQL you can do a lot of complex queries and operations that aren't easy or impossible to be done with JDO. So you have more flexibility but also more complexity.
- Dependent on the database. As I have seen the CREATE TYPE syntax for several databases (DB2, Oracle, Postgres) and the mapping of this types to tables is very different beetween them. Also the performance will vary higher between solutions which makes that an application that flies in Oracle doesn't perform as well in another database. Of course, not everybody can afford the expensive Oracle licenses :)
- Not all JDBC drivers support all the features of JDBC 2.0. As I said one of my frustrations was when I tried to run your example in DB2 and an exception saying that type mapping wasn't supported in DB2 was thrown.
- A very bad solution for systems that uses several databases. In my work for example we use Sybase, Informix and Multibase. Sometimes I get work to my home in which I have DB2, Postgres and MySQL. As type mapping is a technique that not all databases have if your enviroment uses a lot of databases or can change of database commonly Database O/R mapping isn't the best way.
- More complexity. Flexibility is paid with Complexity. You will have SQL and JDBC code mixed with business logic this also will normally be hard to maintain.
Well the advantages and disadvantages of JDO in my point of view are complementary to those of O/R Mapping.
- Separates the persistence logic from business logic. As an implementation of DAO design pattern JDO takes all of its advantages. In O/R Mapping you have mixed your persistence logic with your business logic so both tiers are tight coupled.
- Independence of the database. Your program will work with several databases with the only requirement of changing the xml file in which you declares the properties. So is a great solution for environments with several databases. In my previous example I can download a JDO implementation which supports all that databases.
- As David and Donald said with JDO you can do things that can be done easily with JDBC+SQL as loading complex hierarchies of classes.
- With persistence separated in one independent tier not only you get low coupling between tier but you also get the possibility of improving performance in this tier with caching of objects, connections, data sources, etc.. All of this can be done with JDBC+SQL but with JDO this is performed automatically so easier to upgrade and maintain.
Well I think that I doesn't forget nothing. I wait for your comments. As I said previously I'm relatively newbie to both technologies so don't be very cruel ;)
Thanks for both articles.