Re: Reminder, blatant ad
Date: Fri, 17 Feb 2006 05:38:42 GMT
Message-ID: <CjdJf.9982$yK1.2572_at_news-server.bigpond.net.au>
michael_at_preece.net wrote:
> 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?
Actually I reckon I have done a pretty good demolition job as evidenced by the drawing of such a stinging retort!
Cheers, Frank.
>> - 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 - 06:38:42 CET