Comments on: The Legend of Data Persistence - Part 1 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html Thoughts on software development and project management Thu, 20 Nov 2008 22:37:56 +0000 http://wordpress.org/?v=2.6.2 By: Wahoo http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-12926 Wahoo Sat, 06 Oct 2007 17:24:18 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-12926 Thank you for sharing! Thank you for sharing!

]]> By: Buu Nguyen’s Blog » Unit testing the data access layer http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-12304 Buu Nguyen’s Blog » Unit testing the data access layer Sun, 30 Sep 2007 10:32:17 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-12304 [...] 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 [...] [...] 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 [...]

]]> By: SqlServerForum.org » Blog Archive » The Legend of Data Persistence - Part 1 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-83 SqlServerForum.org » Blog Archive » The Legend of Data Persistence - Part 1 Tue, 20 Feb 2007 04:07:28 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-83 [...] post by Buu Nguyen’s Blog and software by Elliott Back Share and Enjoy:These icons link to social bookmarking sites where [...] [...] post by Buu Nguyen’s Blog and software by Elliott Back Share and Enjoy:These icons link to social bookmarking sites where [...]

]]> By: Nam Le http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-55 Nam Le Wed, 14 Feb 2007 08:08:31 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-55 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. 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.

]]> By: Buu Nguyen http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-61 Buu Nguyen Wed, 14 Feb 2007 07:27:36 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-61 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 :-)) <blockquote>sometimes we're far better off getting out of the problem than struggling with it.</blockquote> Nice saying, I like it. 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 :-))

sometimes we’re far better off getting out of the problem than struggling with it.

Nice saying, I like it.

]]> By: Buu Nguyen http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-50 Buu Nguyen Tue, 13 Feb 2007 02:34:20 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-50 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 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 :-).

]]> By: German Viscuso http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-42 German Viscuso Mon, 12 Feb 2007 04:07:40 +0000 http://www.buunguyen.net/blog/the-legend-of-data-persistence-part-1.html#comment-42 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 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

]]>