Re: Reminder, blatant ad

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Thu, 16 Feb 2006 06:12:31 GMT
Message-ID: <jJUIf.9263$yK1.8008_at_news-server.bigpond.net.au>


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

I rest my case - 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 Thu Feb 16 2006 - 07:12:31 CET

Original text of this message