Re: Relational and multivalue databases

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:oSLZb.94236$jk2.443942_at_attbi_s53...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
news:c13ieq$27a$1_at_news.netins.net...
> >
> > Additionally, it is changes to the data that are very easy in PICK. If
you
> > need to change the cardinality of any field (column-ish) in any file
> > (table-ish), you just do it. Sometimes nothing at all need changing to
> > coorespond, but often an input screen needs a field attribute changed
along
> > with the field attribute in the file. Sure it would be better if these
were
> > in synch, and I'm sure some tools have that, but it is not standard in
> > implementations. Anyway, if you have a report that asks for a person
and
> > their phone numbers when the phone number was single-valued (which it
was in
> > many systems in the 70's and 80's) and then you permit multiple values
for
> > the phone number, the report prints out the new phone numbers too,
without
> > any changes.
>
> It strikes me that this paragraph describes features of Pick's GUI builder
> integration. Now, GUI builder integration is a good thing, but I don't
> believe it has anything to do with the qualities of the data model.
>
> I think we should take care to separate our discussions of data models
> and application integration issues.

Nope -- nothing to do with any GUI, but it does have to do with a database retrieval language -- not SQL. To the extent that SQL discussions have something to do with relational database modeling, the query lanuage that has gone by so many names that it is unknown by any (started out as GIRLS in the 60's and now includes JQL for jBASE, UniQuery for UniData, Retrieval for UniVerse, etc) is a way of talking about the data model underlying PICK. Make sense?

--dawn Received on Sat Feb 21 2004 - 17:53:12 CET