Re: Lucid statement of the MV vs RM position?

From: dawn <>
Date: 24 Apr 2006 03:55:47 -0700
Message-ID: <>

David Cressey wrote:
> "Pickie" <> wrote in message
> > Maybe I ranged too widely in my post.
> >
> > RE Pick's usefulness. I think Pick is in fact a very good DBMS
> > constructor kit. The 'rare expert skills of a dbms developer' are not
> > too much different to having an understanding of the Relational Model.
> > Even with the fairly grunty SQL DBMS toolsets there seem to be a lot of
> > crap design decisions, so maybe forcing people to learn a few
> > disciplines is good?
> PMFJI. I haven't been following this thread, but the above comment caught
> my eye.
> In all the comments made about Pick in this forum, I've never seen it
> descibed as a DBMS constructor kit.
> I have no opinion on that, but I'm interested.
> What really interests me is the idea that a DBMS should be constructed each
> time an application is to be built.
> The way I see it, there are three alternatives:
> Buy a DBMS, and use it as a platform to build the application.
> Buy a DBMS constructor kit, build a DBMS, and use it to build the
> application.
> Build an application on a platform that isn't a DBMS.
> I'm using the word "buy" in the broadest sense, meaning something like
> "obtain and accept". And, of course, I'm oversimplifying, because buying a
> DBMS mey or may not mean buying a programming language to go with it.
> But I would strongly suggest that the level of knowledge of the RM (or,
> presumably, of the MV) needed to design a good database and build a good
> application is quite a bit less than the level of knowledge needed to build
> a good DBMS. And the level of effort needed to build a good DBMS should be
> recovered over many projects, not just one.

I had not seen Pick referred to as a DBMS constructor kit before either, but I do not disagree. I call it a DBMS because there are definitely features beyond a simple file system and I would agree with the vendors of such products that they are database management systems.  However, I did not think it to be a dbms the first time I saw it because it was missing so many features I expected to find. For example, there was no talk of before and after images as I was accustomed to with IMS. There was no prescriptive schema, only descriptive. No one builds these features into Pick when they use their "constructor kit".

They do typically build CRUD services where such thing as referential integrity are placed. And, yes, it does seem primitive to build in RI when it could come with the dbms. However, when you have a philosophy of a descriptive schema (rather than prescriptive), one of the downsides is that you need to roll your own constraint-handling of all kinds. The schema does not constrain.

> For that matter, building a database to support just one application strikes
> me as quaint.

Me too. I have typically worked with enterprise systems, whether Pick or not. I do not think of it as a single-app approach at all.

> But then, my mental set is from another era, when databases
> were thought of as large hubs where entire clusters of applictions came
> together to collaborate by sharing data.

Another era, really?

> I agree with you about the large number of crap designs, which I call
> "stupid database tricks". But I think the solution is to teach better
> design skills, and develop better platforms, rather than to dismiss the
> RM.

We can do both ;-) We ought not dismiss relations, nor modeling with relations, but we do need to go beyond the RM to include lists, for example, which the Information Principle (of the RM) does not permit. Cheers! --dawn Received on Mon Apr 24 2006 - 12:55:47 CEST

Original text of this message