Databases as objects
Date: Thu, 21 Dec 2006 10:04:38 -0500
Message-ID: <y-KdnWr4vo3iPxfYnZ2dnUVZ_oDinZ2d_at_wideopenwest.com>
An unexpected thing happened while debating topmind (over in comp.object): I had an epiphany.
Instead of responding to the news group I thought about it for a short bit (very short) and posted an article to my blog titled, "The RDB is the biggest object in my system."
<http://blogs.in-streamco.com/anything.php?title=the_rdb_is_the_biggest_object_in_my_syst>
What I realized while trying to describe my preference to use DB procedures as the primary (re: only) interface between my applications and the database is because I believe my DB's physical representation of data belongs to it alone and that customers of the DB oughtn't be permitted to directly manipulate (change or query) its data. I realized this is exactly what data-hiding is all about and why expert object oriented designers and programmers emphasize the importance of interfaces to direct data manipulation.
I thought more about this and posted a second article, Databases as Objects: My schema is my class, which explored more similarities between databases and objects and their classes.
<http://blogs.in-streamco.com/anything.php?title=my_schema_is_an_class>
I intend next to explore various design patterns from GoF and Smalltalk: Best Practice Patterns to see if the similarities persist or where they
break down, and what can be learned from both about designing and implementing OO systems with relational data bases.If you agree there's such a thing as an object-relational impedance mismatch, then perhaps its because you're witnessing the negative consequences of tightly coupling objects that shouldn't be tightly coupled.
There's a hypothesis in there somewhere.
As always, if you know of existing research on the subject I'm anxious to read about it.
-- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.Received on Thu Dec 21 2006 - 16:04:38 CET