Re: Lucid statement of the MV vs RM position?

"Pickie" <keith.johnson_at_datacom.co.nz> wrote in message news:1145836622.684579.98260_at_j33g2000cwa.googlegroups.com...
> 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.

For that matter, building a database to support just one application strikes me as quaint. 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.

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. Received on Mon Apr 24 2006 - 10:08:43 CEST