Re: Reminder, blatant ad

mich..._at_preece.net wrote:
> dawn wrote:
>
> > Jan Hidders wrote:
> > > dawn wrote:
> > > > Jan Hidders wrote:
> > > >
> > > >>dawn wrote:
> > > >>
> > > >>>OK, then I'm pretty sure there are no such administrative features that
> > > >>>can be performed on most commercial databases today that require a
> > > >>>change to the logical data model.
> > > >>
> > > >>?? Most of them allow me to add indexes w/o changing the logical model,
> > > >>or change clustered indexes to non-clustered ones, for example.
> > > >
> > > > ? Yes, that is what I was saying...? It was perhaps convoluted
> > > > wording, so maybe you read it wrong?
> > >
> > > Ah, yes I did. But then, depending on what you define as "the logical
> > > model", your observatoin is besides the point. This is not what
> > > distinguishes DBMSs that feature physical data independence from those
> > > that don't.
> >
> > For this purpose we can just talk about the application code that
> > interfaces with the database. I have not seen any physical database
> > changes that have prompted changes to the application dabase code
> > (CRUD) or metadata, other than possibly some data source hard-coding.
> >
> > > For example, in the extreme case where there is no physical
> > > data independence and the logical and physical model therefore coincide,
> > > the only way to change the physical model is by changing the logical
> > > model,
> >
> > Can you think of a a specific customer requirement for their software
> > (likely related to an ility) that can be handled by an RDBMS (or
> > SQL-DBMS) but not by these products where the physical model more
> > closely aligns with the logical model?
> >
> > > and so even in that extreme case there are no separate
> > > administratieve features that require a change to the logical model.
> >
> > OK, so we are not looking at a required change to the physical model
> > prompting a change to the logical model while that is how I had
> > understood why there was a requirement for data independence.
> >
> > My reason for asking is that I believe there must be some advantage
> > that an RDBMS software solution has over an MV solution related to this
> > data independence (because I'm pretty sure that folks would say that MV
> > does not have data independence)
>
> You can do what you like with Pick. 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.

If Mike is right about this, that might explain my confusion, eh? My thinking when I read Codd was that PICK did not have data independence and that it didn't matter one lick. But then Jan said that what he would need in a non-RDBMS for it to be viable was data independence, which made me think it was more important than I had thought.

I won't claim that I have full comprehension of this topic (or any topic, for that matter), but I really do appreciate your explanation. Thanks. --dawn Received on Thu Feb 16 2006 - 03:17:26 CET