Re: In favor of a model / theory

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c9i261$bvd$1_at_news.netins.net...

> Just for the record -- Agreed!

I'm glad we're in agreement about something. And it looks like something important to me. Just from reading all you've written, I've surmised that you and I have somewhat similar views about the relationship between theory and practice.

>
> For example, if it didn't trouble me that the current state of the
"theory"
> was out of step with what I have experienced, I would do as many do and
> stick with what works, not giving it another thought. I'm on a quest to
get
> theory and usefulness aligned, at least better than it is today. Those
who
> believe it to be there already are fortunate -- it is troubling to have
> one's beliefs (previously for me that was relational theory) be so out of
> step with one's experiences.

My experience does not parallel yours, but that shouldn't surprise either one of us. I have a hard time following your experience, never having experienced PICK first hand.

But I'll venture to suggest that there are a lot more differences going on here than just the difference between data models.

For example, one of the features of PICK that I think you've mentioned is that it is what I'll call "self contained". That is, it can avail itself of all the services necessary, from storing data in files, to presenting data on forms, to data capture or entry, etc. etc., without the developer having to learn some other tools, and integrating the tools together with PICK. This is enormously important in terms of the scenario you've outlined where a subject matter expert became enough of a PICK expert to implement an application, and that application has been useful over a long time. The biggest obstacle to a not IT person isn't learning a single tool. It's learning how to use multiple tools together, none of which were built to be used together.

But among what this crowd calls "SQL databases", there is an enormous variation of how "self contained" they are. If I compare DEC Rdb and Oracle RDBMS, for example, I'd say that there is such a thing as an "Oracle application", but no such thing as an "Rdb Application". There are applications that use Rdb, and even have it at the center of their dataflow, but the applications are "COBOL applications" or "C applications", not "Rdb applications". I don't know if this distinction makes any sense in terms of your experience.

And "Oracle Applications" have a considerably different feel to them than "C applications that use Rdb".

>
> So I went back to the origins of relational theory in researching it -- to
> see what the mathematical model was intended for. Codd's ACM paper from
> 1970 (that he wrote in '69 and researched ahead of that) was great.
> Subsequent work, including Oracle and SQL, seems to have taken us down the
> unfortunate path of 1NF and rigid DBMS's (costing companies significant
> dollars).
>

Here I differ with you. I think that what you call the "unfortunate path of 1NF" was explicit in the 1970 Codd paper. I think the unfortunate things happened later, but I think that your quarrel is with the paper itself. Received on Tue Jun 01 2004 - 17:29:25 CEST