Re: Reminder, blatant ad

Frank Hamersley wrote:

> michael_at_preece.net wrote:
> [..]
> > You can do what you like with Pick.
>
> I rest my case

Is your case labelled Frankly Harmless?

> - the rest is a mere bagatelle!
>
> Cheers, Frank.
>
> > PickBasic applications read data
> > and access it as part of an ordered list - part of a delimited string.
> > REC<1,2,3>, for instance, accesses the 3rd subvalue in the 2nd
> > multivalue in the 1st attribute of a record. The "1", "2" and "3" can
> > also be by reference rather than by value - so the "1" could be
> > ProductCode, for example, and ProductCode could be assigned or equated
> > to "1" elsewhere. Suppose you have a legacy application that's been
> > running for many years and the code is littered with these direct
> > references. This appears to run counter to the concept of data
> > independence - but it ain't necessarily so. All you have to do to
> > achieve data independence in this scenario is call a subroutine to
> > obtain REC rather than READ it directly. What goes on in the subroutine
> > that delivers REC to your application is entirely up to the developer.
> > It might be sourced from a single "record", or "item", in a single file
> > (typical) or it might be "compiled" from various sources. The more
> > sophisticated development environments have parameterised options for
> > controlling this data abstraction - so that the developer need not
> > change any program code at all in changing the database design. Try
> > googling CDP for "Data Abstraction Layer" if you want more details.
> >
> > On the subject of the distinction between the physical and the logical
> > :- I reiterate that the clear demarkation that exists in the SQL world,
> > where the SQL engine clearly seperates one from the other, is absent in
> > Pick. Pick is entirely logical.
> >
> > Cheers
> > Mike.
> >
> >
> >>and I haven't figure out what it is.
> >>I'm hoping to understand it well enough that I could explain it to
> >>another MV person who does not have any background with the RM. I
> >>would like it to be in terms of a requirement (even if a quality, ility
> >>requirement) that can be met by an RDBMS but not by an MV system.
> >>
> >>
> >>>>Any ideas on a VSAM example of where a physical model change would
> >>>>prompt a logical data model change? (that was at the end of this
> >>>>message)
> >>>
> >>>Well, if the fact that your data is stored in VSAM files is part of the
> >>>logical data model,
> >>
> >>I didn't, but I can see where that could be a valid way to view it.
> >>
> >>
> >>>then if you would change that to, say ISAM files,
> >>>then you would have to change the logical data model.
> >>
> >>So is data independence about data sources and having a language for
> >>the interface to the dbms that can be used for multiple databases? If
> >>you decided to point your COBOL or Java Oracle application at OpenQM
> >>(an open source PICK database openqm.com) you wouldn't exactly be able
> >>to do that without changing your application either. Does that mean
> >>that Oracle does not have data independence (no, I didn't think so).
> >>
> >>I clearly still don't grok this data indie thing. I don't know who
> >>(the end user, the developer, the system administrator, the dba) is
> >>impacted by this problem that is solved by an RM approach to data
> >>independence nor how it is solved. I'd like figure out an example of
> >>where the lack of data independence bites a Berkeley DB, Cache', MV...
> >>developer, for example.
> >>
> >>Thanks. --dawn
> >
> >
Received on Fri Feb 17 2006 - 02:17:45 CET