The Legend of Data Persistence – Part 1
Endnotes
1 Those are two major goals, sophisticated O-R/Ms are also expected to provide full-blown support for value-added services such as caching and transaction management etc.
2 JDO (JSR 12) is a specification whose major objective is “to provide a transparent, Java-centric view of persistent information stored in a wide variety of datastores” [Jordan & Russell, 2003] which can be relational database, object database, proprietary Enterprise Information Systems (EIS), or any kind of data repository. A JDO’s implementation for RDBMS can be considered an O-R/M tool
3 To be exact, since iBATIS does not hide SQL, a property of the relational world, from application developers, it is not really an O-R/M tool
References
- [Begin et al, 2007], iBATIS in Action, Clinton Begin et al, Manning, 2007
- [Bauer, King, 2007], Java Persistence with Hibernate, Christian Bauer and Gavin King, 2007
- [Fowler, 2002], Patterns of Enterprise Application Architecture, Martin Fowler, Addison Wesley, 2002
- [Jordan & Russell, 2003], Java Data Object, David Jordan and Craig Russell, O’Reilly, 2003
- http://en.wikipedia.org/wiki/Object_database
- http://en.wikipedia.org/wiki/Relational_database_management_system
- http://en.wikipedia.org/wiki/Object-Relational_impedance_mismatch
- Other websites: Hibernate, EJB, BATIS, Active Record, DB4O, JDO, LINQ
Categories: OOAD, Software Engineering dao, db4o, design patterns, impedance mismatch, odbms, orm, rdbms
Hi!
Very good article! In your intro you say:
“In Part 2, I will introduce the readers to ODBMS, its benefits, and the reasons why it still cannot replace RDBMS”
I think that’s not really accurate since usually an ODBMSs such as db4o is used where an RDBMS doesn’t make sense (it’s a matter of context).
So I think that perhaps it would be better to use something like this:
“In Part 2, I will introduce the readers to ODBMS, its benefits, and the context in which it still cannot replace RDBMS”
What do you think?
Thanks a lot!
German
Thanks for you comments, German. You’re right that the decision as to whether to use ODBMS or not is context-sensitive. However, currently I am thinking I would discuss this in a general sense (i.e. despites its benefits, why ODBMS cannot replace RDBMS [and that would include the disadvantages of ODBMS]) and let the readers, based on this information, decide whether ODBMS is the right choice for their specific context or not. But I’ll may adjust the statement you mentioned above when Part 2 actually comes out
.
Thanks, Nam. I agree with you that some people tent to think that DB is the only way to handle persistence in the applications and throw out all kinds of excuses (e.g. not scalable, not secured, lack of concurrency control etc.) for not using other mechanisms such as XML/binary serialization or even flat file (even for very small projects). The point is to use the tool that is most appropriate to your problems (but this is often easier said than done
)
Nice saying, I like it.
Nice post. You have done a very good job on summarizing what a developer/architecture should be awared of when choosing an ORM approach.
However, data persistence has a much broader scope. It always surprises me that people think of RDBMS as the only storage mechanism for data persistence. Sometimes, flat files are far better off in terms of performance, development speed, and flexibility.
Actually, I was so glad that I had made some brilliant decisions on using simple object serialization/deserializing (either binary files or XML files) as a persistence layer instead of RDBMS. Many years in this industry has NOT taught me how to solve the ORM problems effectively and completely, but I do learn something useful: sometimes we’d far better off getting out of the problem than struggling with it.
Surely RDBMS is not always the right answer; however, I am looking foward to your later posts about ODBMS.
Thank you for sharing!