Re: Object-relational impedence
Date: Mon, 03 Mar 2008 19:02:40 -0400
Message-ID: <47cc8395$0$4060$9a566e8b_at_news.aliant.net>
Roy Hann wrote:
> "Thomas Gagne" <tgagne_at_wide-open-west.com> wrote in message > news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d_at_wideopenwest.com... >
>>JOG wrote:
>>
>>>I wondered if we might be able to come up with some agreement on what
>>>object-relational impedence mismatch actually means. I always thought
>>>the mismatch was centred on the issue that a single object != single
>>>tuple, but it appears there may be more to it than that.
>>
>>The issue as I've discovered it has to do with the fact OO systems are
>>composed of graphs of data and RDBs are two-dimensional.
That is a remarkably uninformed and ill-conceived sentence. It's rather like comparing boats and cars saying boats have hulls and cars are pretty. Regardless of truth, the comparison is pointless on its face.
The Great Debate was had about 3 decades ago and graphs lost. Nothing has happened in the meantime to improve the outcome in the favour of graphs.
> RDBs are not two-dimensional, they are n-dimensional. You are confusing the > picture of the thing with the thing. I have a three dimensional kitchen > table. I have an RDB table with three columns (dimensions) called length, > width and height that describes it. > >
>>What defines an account in an RDB may be composed of multiple tables.
>>An RDB might express multiple account types through multiple tables
>>where OO may reflect it as multiple classes. Attempts to make RDBs
>>function as graphs through mapping tools results in disappointing
>>performance and, in my experience, too much mapping, too much
What moron would want to make an RDB function as graphs in the first place? We have known for 3 decades that graphs, themselves, result in disappointing performance and too much mapping. After all, every time one adds a new structural element, the design choices increase geometrically with no logical justification for choosing among them.
This leads people to discard logical independence and invent physical reasons. The arbitrary design choices then lead to query bias that effectively makes large numbers of useful queries prohibitively expensive to write or to execute.
>>infrastructure, and too much language/paradigm-specific layers. In
>>short, way more code, way more maintenance, and way more job-security
>>for consultants, pundits, and tool providers.
> > I completely, 100% agree with that. Code is evil. > > RoyReceived on Tue Mar 04 2008 - 00:02:40 CET