I was the guest lecturer in a database class last week, something I
have done for the past several years. Since I have my "Is Codd Dead?"
talk that I gave at the Seattle Area Pick User Group last year, I was
able to reuse some slides from that and also show part of the Cache'
MV demo video (from http://www.intersystems.com/mv ) where you can see
the same data being handled by Pick, SQL, and as objects in Cache'.
The professor sent me an e-mail this morning and it included this
quote:

"Thanks again for visiting my class. The student responses were very
positive. One student wondered how people could continue to use the
relational model and SQL when such a superior approach is available.
I think you reached them."

I think I finally have this talk down. Woo hoo! --dawn

It would be interesting to know if they were more awed by the multivalue
model or by the object model.

If you love multivalue, you'll really love objects.

dawn wrote:

On May 7, 12:04 pm, sh <sham... (AT) prupipe (DOT) com> wrote:
Yes, I have to pick and choose what to address and I did not overtly
discuss objects other than the OO-RM mismatch, which goes away with
either PIck or "object databases." I knew this group had all taken
Java courses, so they knew OO already. I did not how any MV BASIC,
but did talk about it as a 3GL.

I compare this SQL statement

SELECT LAST_NAME, FIRST_NAME
FROM
STUDENTS S1,
STUDENT_MAJORS M1
ON S1.STUDENT_ID = M1.STUDENT_ID
WHERE
"PHIL" NOT IN
(SELECT MAJOR
FROM STUDENTS S2, STUDENT_MAJORS M2
ON S2.STUDENT_ID = M2.STUDENT_ID)


With this MV query statement:

LIST STUDENTS NAME WITH EVERY MAJOR <> "PHIL"

to illustrate differences, but do mention that with SQL you can write
queriest to get out all data you might want without any virtual fields
or 3GL coding, which is not the case with Pick, in general.

So, they do see more than just OO. cheers! --dawn

When I was at CeBIT in Germany I was asked to sit down with someone I
was told was a "database expert", to go over the MV model. In about
15 minutes I described the model, created a database, a schema,
queries, and a data entry screen and other programs in BASIC. [I'm
sure some people would ask why it took that long. ] He said MV was
the closest thing he had ever seen to a real object-oriented database
- everyone sees something different in this model I guess. Today I'd
refer to Caché as object-oriented and MV simply as "easy and
efficient".

I had a similar opportunity many years ago to give a room full of
RDBMS guys an overview of MV. (This was a demo to explain to Omnis
people what the Pick side of the RD business was about.) They "got
it" very quickly when given simple examples which put MV concepts in
SQL terms. That's really the secret, I think - explaining it in
familiar terms, rather than (as I've seen it done) starting with
"forget everything you've ever learned about databases...".

Given the opportunity I'm sure we could turn more heads. Such
opportunities however are quite rare, and this community doesn't pay
people to be evangelists.

T

dawn wrote:

On May 7, 5:43 pm, Tony Gravagno
<address.is.in.po... (AT) removethis (DOT) com.invalid> wrote:
What do you mean, Tony? Am I the only one getting checks in the mail
from IBM, jBASE, Revelation, Ladybridge, Raining Data, InterSystems,
etc for talking about the MV data model? Hmmm. I'll split it with
you. Smiles. --dawn

<snip>
What do you mean, Tony? Am I the only one getting checks in the mail
from IBM, jBASE, Revelation, Ladybridge, Raining Data, InterSystems,
etc for talking about the MV data model? Hmmm. I'll split it with
you. Smiles. --dawn

Hi Dawn
I am sure that you would be getting CHEQUES from Ladybridge :-)
A beautiful example of SQL/Access,Recall etc. I have saved it.
Keep up the good work
Peter McMurray

Tony Gravagno wrote:
I was thinking of Cache when I made the statement. The fact that
multivalue can be treated as a subset of object-oriented says a lot
about the object model.

Your statement that mv is "easy and efficient" is well taken. Sort of
like "get 80% of the results with 20% of the effort". OO might be the
grander model long term, but it takes more effort to set up the initial
schema.

And don't forget that QM has OO programming integrated into the
QMBasic language. I have seen some very clever things done with this.


Martin Phillips, Ladybridge Systems Ltd.

This does surprise me, since - as has been discussed many times on
here already - the relational model supports list types already (as do
most modern implementations) - so the multivalue "advantage" of pick
isn't unique

Were these new students, unfamiliar with modern approaches to
database? If not, for example if they have seem Ruby on Rails
Migrations (or - better yet - the Hobo extensions to Rails
migrations), then I am surprised by their response.

I know a lot of folks on here are hoping that one day pick will become
mainstream - but the modern alternatives out there are so compelling
that I cannot see it ever happening.

Anthony Lauder wrote:
The amount of effort required is much greater to accomplish
the same task. To print errors out of a file.
Select (also required in relational)
Loop (also required in relational)
read (also required in relational)
until (conditional also required in relational)
Print (setup is a pain in relational)
repeat (end of loop)
In relational I would have to define the methods and properties.

There is way more programming effort in most mainstream technology.
Iron is cheap. Software development is expensive.
Less software required = quicker and more cost effective solutions.

My 2, Patrick <;=)