The Legend of Data Persistence - Part 1
1. Abstract
Have you ever felt frustrated for having to develop applications whose back-end making use of a Relational Database Management System (RDBMS), such as MS SQL Server, or Oracle? Do you think it is a pain to write SQL (or stored procedures) to query some data and then manually map the result set to your object model and back? Great, you have Hibernate, EJB, iBATIS, and Active Record, but do they really really make the work of object-relational mapping (O-R/M) simple enough and completely transparent while imposing no compromises to the richness and expressiveness of the object model? If O-R/M is such a big problem, why do we not use an Object Database Management System (ODBMS) instead? And if ODBMS is possible for certain applications that we are developing, which ODBMS implementation can we use at a start?
In this three-part article, I will attempt to provide the answers to all the above questions. Please note that most of the concepts and tools described in this article will certainly take more than just one or two pages to be fully presented (in fact, 500-page+ books have been written for several of them), thus I will not discuss in dept about any particular concept or tool - instead the aim is to provide a high-level overview of the key points and interested readers are recommended to learn about the specifics via their own research (the References section can serve as a start)
Okay, with that in mind, the contents of the article are organized as follows:
- In Part 1, I will discuss about the object-relational (O-R) impedance mismatch, its consequences, and ORM tools as a rescue
- In Part 2, I will introduce the readers to ODBMS, its benefits, and the reasons why it still cannot replace RDBMS
- In Part 3, I will introduce the readers to DB4O, one of today’s most popular ODBMS implementations
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 :-).
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.
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.
[...] post by Buu Nguyen’s Blog and software by Elliott Back Share and Enjoy:These icons link to social bookmarking sites where [...]
[...] and the SQL statements or stored procedures executed as part of an interaction (and if you use an ORM framework like Hibernate, the complexity of the mapping rules adds up to that [...]
Thank you for sharing!