Re: Dreaming About Redesigning SQL

Originally posted by Bob Badour

> "Alfredo Novoa" <alfredo_at_ncs.es> wrote in message

> news:e4330f45.0310240041.62b42630_at_posting.google.com"]news:e433-
> 0f45.0310240041.62b42630_at_posting.google.com[/url]...

> > michael_at_preece.net (Mike Preece) wrote in message

> news:<1b0b566c.0310231728.4e643b71_at_posting.google.com>...

> > > Correct me if I have this wrong:

> > > What you're advocating instead is a function of the DBMS. It
> isn't a

> > > function of the Pick DBMS.

> > This is one of the many reasons because Pick is a primitive
> file

> > procesor that does not deserve attention.

>

> To amplify a little: If it is a function of a dbms but not a
> function of

> Pick, then Pick is not a dbms. Simple, no?

Bob's penchant for twisting words not withstanding...

Maybe I was a little hasty in saying that centrally enforced integrity constraints are not a function of the Pick DBMS. I guess it's all relative really. It depends on what is meant by "the Pick DBMS".

Don't take what I'm about to say as gospel - it's just my best shot at explaining the evolution of the Pick DBMS and it's functionality into what it is today. I'm sure it won't be perfect and would welcome corrections.

Traditional Pick took a blob of raw filespace from the host file system and implemented a virtual machine environment within that blob, managing all of it's functionality. A kind of DBMS with bells on. All of the component parts of a computer system were functions of the virtual machine - DBMS, OS, application development environment, the lot.

Some Pick variants very early on in the piece devolved responsibility for managing aspects of the system to the host OS - Unix. That was how IBM's U2 flavours got started - and how they got their "Uni-" prefix. By doing so they were able to avoid many of the difficulties faced by the vendors of traditional flavours of Pick with regard to meeting the accelerating demand for device drivers etc. etc.. They also offerred more in the way of interaction with other Unix devices/processes.

Eventually pretty much all flavours of Pick went a similar way to a greater or lesser degree. In D3 on *nix, for example, the database management functionality was retained within a blob of raw file space still known as the VME, but OS functions were devolved to the host (NT or *nix).

The point I'm getting to is this: We are used to thinking of Pick as having different parts of a whole. There's a development environment for PickBasic, a "Proc"edure language, a query language, a terminal control language, a spooler, a device manager for managing files on different media and file systems, a background task scheduler and manager, update and ouput processors and all the rest... and it all exists in Pick files on the Pick database. Taken as a whole then, can the whole kit and caboodle be called a DBMS? If it can, then could every function of Pick be said to be "centrally embedded within the DBMS"?

Mike.

--
Posted via http://dbforums.com