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.

The really astounding thing about Dawn's paragraph above is the "you just do it" part. As I explained at length and ad nauseum in the "red blue car" thread, when you just do it, you just change the meaning of existing queries. Received on Sat Feb 21 2004 - 18:16:11 CET