Re: Relational vs network vs hierarchic databases

"erk" <eric.kaun_at_pnc.com> wrote in message news:1100784119.913833.67870_at_z14g2000cwz.googlegroups.com...
> Dawn wrote:
>
> > Referring only to the structure, not the implementation, the way that
> people
> > think often aligns better with a graph model than a relation. This
> says
> > nothing about the implementation, but the high level view of the
> data.
>
> I agree, and furthermore a graph like the web lends itself to messy
> evolution (which was necessary to ensure any evolution in the case of
> the web).

agreed

> But data to support a business must also support consistency
> and efficient processing, not just people following the data in a way
> aligned with their thinking - that's what apps are for.

absolutely agree

> > If the implementation were identical, then yes, but a business whose
> data
> > model is based on a graph rather than a set of relations does just
> fine.
>
> Not really - why does Pick have files, then, rather than a single
> graph?

From the users perspective, they view everything they are looking for through a single file at a time. The graph of data looks to the end-user as a single file and to the developer as a node through which you can traverse to any other node of interest. The Pick approach to a graph definitely has flaws, but performance definitely isn't one of them.

> And the Pick nested-list model is a rather limited and ridig
> form of a graph (I mean "degenerate" not in a derogatory sense).

yes, agreed.

> Why
> can't I have an element nested 2 lists deep, like a line item on an
> order, "point" to a top-level file like Customer?

You can, if I understand the question.

But, again, it isn't perfect, just seemingly yields higher productivity with ongoing maintenance.

> > I've found the graphs to be far less rigid than relations, but still
> haven't
> > put my finger on why that is.
>
> To use relational phrasing, that's because changing links between nodes
> effectively changes the predicate on which that node is based. That's
> fine, but that has logical consequences.

Yes, just as creating a new view gives us a new predicate.

> > I still suspect it has to do with the reasons
> > why the web caught on -- it thinks something like people do.
>
> Since AI imploded, I'm suspicious of attempts to make computers "think
> like" people.

Agreed. I'm interested in the interface between the machine and the person being useful and easy to use for the person. The machine itself can think like a machine, and the person can adapt to think more like a machine, but to minimize errors we can present a user interface that is as intuitive for the human as feasible. So, if relations are something the computer likes for implementing an organization chart, that's fine, but does the person interacting with the computer (the IT professional modeling the data) need to think like the computer?

> I'm especially suspicious given the Access databases
> end-users like to cook up...

Absolutely!

> > Back to
> > reading -- I'm determined to learn enough that I can understand what
> I have
> > seen to be either a fluke or to be attributable to xyz.
>
> The Watt book?

I've finished it. You might have been beyond it, but I had never read about the development of computer languages before and really liked it. However, the same comment that you mentioned in another thread -- the Date issue of Feb 31 -- was something I had to read in context about 5 times to try to figure out what I was missing. I couldn't imagine that he would want to be so lax with other types. I was especially interested in where scripting languages fit into the puzzle since I have avoided learning any (although I've read and debugged a Perl script before).

> If so, I'd recommend something by Luca Cardelli - he has
> plenty of online papers, and while he's a little formal, it's very
> readable.

I'll take a look. Thanks.

> > Cheers! --dawn
>
> Not since the election, but thanks anyway.

I know, I know. I'm sitting here in the reddest county in Iowa, feeling blue. --dawn

> - erk
>
Received on Thu Nov 18 2004 - 15:19:21 CET