Re: Relational and multivalue databases

"Bob Badour" <bbadour_at_golden.net> wrote in message news:u5GdnY96wOoMD6rdRVn-hQ_at_golden.net...
> "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.
>

Bob -- I'll admit I do not understand your red blue car issue. Could you spell it out for me? I would appreciate it. thanks. --dawn Received on Sat Feb 21 2004 - 18:35:06 CET