Re: Relational vs network vs hierarchic databases

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Fri, 19 Nov 2004 23:56:20 -0600
Message-ID: <cnmmat$75$1_at_news.netins.net>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:vL-dnW7o3vjB6QPcRVn-qg_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cnlebu$736$1_at_news.netins.net...
>
> > I agree -- that was not what I intended as the point.
> > It was in this instance -- where a person is thinking of an
organizational
> > hierarchy -- where I indicated that I don't care how the computer is
> > handling the implementation of the org chart -- the person doesn't HAVE
TO
> > think like the computer. In theory, the person could specify a
hierarchy
> as
> > a hierarchy and use it as a hierarchy, but the underlying structures
could
> > be relations. Today we do that for the end-user, but not for the
> developer.
> >
> > Did that make sense? --dawn
>
>
> Yes, but....
>
> Earlier you referred to the "IT professional" as "data modeler", and now
> you're referring to the "developer".
>
> It's not the same body of expertise, and not the same requirement for
> thinking in models.

I've been working in the SME arena and with products that lend themselves to IT professionals (which I use as the broad category) who are both software developers and data modelers. The relationships I had between these entities were that a software developer is-a IT Professional and a data modeler "is-a" software developer (even if not a "programmer"). I do realize that this might not be everyone's experience and I'll try to tap into the large shop thinking when using those terms in the future.

> As far as programmers is concerned, I wouldn't mind if they had a layer
of
> interface that made the relations look like hierarchies, when needed.

And those who create the schema could do the same. We could get rid of the XML and OO to RDBMS impedence mismatch. The industry isn't close to migrating away from OO languages, nor from XML, but we could move away from an interface to our data and metadata that is so dissimilar.

> But
> access to hierarchies coded as either adjacency lists or nested sets
isn't
> all that tough, even for a programmer.
> Hell, I wouldn't mind a layer of
> interface that made pick files look like tables.

I've worked with that for several years (odbc & jdbc to U2, for example) -- it's a way to take the worst of each world and put them together ;-)

> BTW, I assume your org chart comments don't contemplate something like
> "matrix management".

Yes, definitely -- thus my usual terms of "graph" or "di-graph". I used the term "hierarchy" only to help make the point clear to the broadest audience (although I guess this ng isn't exactly a broad audience, eh?)

Cheers! --dawn Received on Sat Nov 20 2004 - 06:56:20 CET

Original text of this message