Re: Another idea from pick goes mainstream...
- From: "dawn" <dawnwolthuis@xxxxxxxxx>
- Date: 14 Apr 2006 07:32:00 -0700
Jim Idle wrote:
Albert D. Kallal wrote:<snip>
I can remember in the early 90's how big of a deal was variable length
fields for a database - this would save lots of disk space when it cost lots
back then!! .....again, pick had that from day one!!
Well, again, be careful, because varaible length records were not new
to Pick particularly. It is possible that Pick was a very early
implementation of such concepts. The intent of other databases was to
implement the relational model in a commercially succesful way, not to
think about storage per se. A relational database has nothing to do
with physical storage (nor SQL really)
I feel a need to nitpick on that statement. SQL is one of the
languages that was written for the purpose of implementing the
relational model (QUEL being another). SQL won the language wars and
is now considered THE language for any dbms implementing the relational
model. Even those that speak other languages (try to) also speak SQL.
While it is possible to specify other languages that employ the RM,
likely more accurately than SQL (tutorial D, for example), SQL is the
top dog in relational database languages. So it would not be accurate
to say that a relational database has *nothing* to do with SQL, even if
it would be possible to implement the relational model using a
different language as the interface for the user.
and variable length records are
more of an application programming convenience than anything else.
Handling such things lower down starts to make things less efficient
rather than more efficient (other than storage, potentially, but few
care about that these days).
variable length everything (records, fields, array sizes for
multivalues...), where the length designation in a dictionary is
descriptive, rather than prescriptive, is something I have only seen in
Pick (but that doesn't mean it isn't elsewhere).
I can remember all the hype about how Java is a p-code system with a
runtime. Makes it easer to port the system to different processors. Of
course we all know that a LARGE number of vendors used to exist for pick
systems..an they ran on every concavely conceivable of the day. (And, so is
the new .net stuff). Again, pick was a p-code based system. p-code
architectures are in vogue today...and we had that since day one (java and
.net are both these types of systems).
Again, the Pick operating system did not engender the idea of an
interpreted P code system. In fact, if you are referring to the way
BASIC works, it was not until quite a bit later that such a thing
turned up. Before that you had PROC, which was purely interpretted
text, which certainly was not interpretted, and a few other things that
are lost to the mists of time for most. I suspect that Ken used a pcode
for Pick BASIC because it was the easiest way to fit it in; I also
prefer to think that he wrote it so he could write Star Trek for Pick,
though he denied it. I also think that the birdmen are coming... ;-)
I prefer to think that Star Trek was at least a minor part of the
picture of why he wrote data BASIC too. I used to carry home an ADDS
terminal and 300 baud modem to work from home and made sure to show to
dial in to show my friends Star Trek running on a Pr1me 300 (written in
Fortran).
The Java pCode engine is touted too much of course. If it was any good,
then you would not need a JIT to make it perform (after it has used
38MB of memory to load the pcode that is). It is well organized and
sensible for easy porting, but it is organized in a way that makes it
difficult to perform. A JIT compiler can still be a good idea, but it
is sad if you MUST have it for performance.
Then, XML came out. This hot new idea was a delimited string that could
represent a whole invoice. You think this was the hottest new idea on the
planet....again, pick has this delimited string concept from day one......
Well, again, XML can easilly model the delimited strings of Pick, but
Pick cannot easilly model the things that XML can.
Agreed. XML covers documents in a way that Pick doesn't.
While XML has been
hijacked in to all sorts of uses that it should not be used for, and
has expanded quadratically in complexity such that you need 72 external
libraries to be able to deal with all the possible things that are now
"XML".
At the end of the day though, the fact that XML can easily model a Pick
delimited record is just coincidence, as XML, even in its original
formulation contains much that PIck does not.
I'm gonna nitpick on that one too. Relational databases employ a
perspective of data modeled using a mathematical model of relations
(which are sets). Both XML and Pick originated with the concept of
data modeled using a lanaguage model. In the case of Pick, it is
related to the language of questions and answers about pieces of
collected data. In the case of XML is it related to the language of
documents about words, sentences and paragraphs. In both cases,
language is at the root, rather than mathematics. That is why it is no
coincidence that these models look more similar than the relational
model looks to either of them.
Then there is multi-valued fields....The new version of ms-access has
multi-valued fields..(here is a video..and multi-value fields are
mentioned).
http://www.microsoft.com/office/preview/programs/access/demo.mspx
The term multi-valued is unfortunate, but only for Pick and MUMPS.
Multidimensional means something else here.
Funny, each time some vendor points out how some new great feature is in the
marketplace, It seems it always came from pick!!
Though it is tempting to believe that, I am not able to agree with it
very much. There are a few common concepts that almost certainly
evolved independantly, but at the end of the day, a realational
database has few things in common with the Pick/MV model
but more each year, which was Albert's point. While most RDBMS tools
did not support complex data types such as arrays as data values in the
past, many now at least support relation-valued attributes, resembling
MV (without the ordering in the mv's). If it is the case that SQL
Server supports a 2VL (if you set it up that way), then that's another
improvement to make it more like MV. SQL Server's UDF's are very like
virtual fields in MV, including array-valued UDF's in the mix. So, I
do think that the RDBMS's are catching on and incorporating more and
more aspects of what we already have in MV.
and the
technolgies developed to go with the relational model did not have MV
models as their basis.
Definitely true.
Somehow, I feel opportunities where missed along the way by mv vendors....
It is certainly true that more could have been and still could be done.
I personally believe that I am working at a company, in Intersystems,
that sees that very clearly. In fact, a lot of the work I am doing is
to enable MV to catch up with the technology integrations within Cache.
I hope I managed to say that without too much advertising being
involved!
I look forward to seeing what you guys have done and very interested to
see how it is marketed. Cheers! --dawn
.
- References:
- Another idea from pick goes mainstream...
- From: Albert D. Kallal
- Re: Another idea from pick goes mainstream...
- From: Jim Idle
- Another idea from pick goes mainstream...
- Prev by Date: Re: My copy command is not working the way I think it should
- Next by Date: [OT] Re: Migrate data to MS SQL from D3NT
- Previous by thread: Re: Another idea from pick goes mainstream...
- Next by thread: Re: Another idea from pick goes mainstream...
- Index(es):
Relevant Pages
|
