Re: 3vl 2vl and NULL

"dawn" <dawnwolthuis_at_gmail.com> wrote in message news:1133957782.055492.30440_at_z14g2000cwz.googlegroups.com...
>
> Frank Hamersley wrote:

> > BTW - I did giggle at the use of the generic term "languages" to expand
> > the domain in your favour by letting the "database" aspect of DC's post
> > fade.
>
> I wasn't intending to expand the domain. My interest in database
> theory and data modeling is related to the area of software
> development. You might carve out another domain related to your own
> purposes for chatting about database theory. In response to your
> statement that 2VLs were not a "success story" (that I don't see or
> inadvertantly snipped in this posting) I would certainly disagree.
> Developers often write software that uses very current technology on
> the front-end (e.g. AJAX) by using exclusively two-valued logic, often
> then working with SQL on the back-end. I prefer to employ a 2VL (along
> with non-1NF) end-to-end and I suspect that approach is on the rise.

Frank and Jon,

This discussion, in various guises, has been going on for years now between Dawn and me.

I tend to view databases as being important to informatica principally due to the information sharing services that databases provide, and only secondarily due to the information storage services. Dawn's view, as near as I can make it out, is a process-centric view of the service of information sharing. Those two views collide all the time, and at various levels.

For purposes of the present discussion, it's useful to refer to one of the phrases in Codd's twelve rules: "data sublanguage". I think Codd chose words advisedly, and I think he chose "sublanguage" rather than "language" for a reason.

Now the question might arise, "Is SQL a data sublanguage or is it an application programming language"?

I tend to think of it as a data sublanguage with delusions of grandeur. In particular, Oracle has implemented its dialect of SQL, and its PL/SQL extension, with the idea that entire applications can and should be written in Oracle. I'm not satisfied with that. It's possible to write entire applications in Oracle's dialect of SQL or PL/SQL. I've done it. But that doesn't mean it's a good idea. All of the successful projects I've been involved with that use Oracle use it in conjunction with something else:

Either COBOL, FORTRAN, BASIC, C, PL/1, Pascal or something like that. Or, on the other hand, Business Objects or Cognos power play, or something like that.
Or maybe FOCUS, or Crystal Reports or something like that. Even when I was using DEC Rdb, I often used it in conjunction with DEC Datatrieve.

In that sense, viewing database theory as fitting into a larger picture, there's probably less difference between me and Dawn than meets the eye. However (and it's a big however) just as Dawn doesn't feel that database designers are capable of defining the world for application programmers, I feel that application programmers are not prima facie competent to design databases for the purpose of data sharing. That doesn't mean that programmers can't learn that skill and art. It just means that there is some significant learning that must go on before a seasoned programmer can become a good database designer.

And data sharing is where, in my view, you get the bang for the buck out of database development. I suspect that almost all of the projects that have yielded disappointing "bang for the buck" using products like Oracle are projects where the amount of data sharing is so small, that a less ambitious approach (like using Pick) might have yielded the same results, with less time and expense.

What I think Dawn is missing is the big picture about "large shared databases". And I just about concur with "Spight'sLaw": sooner or later, you're going to need a DBMS. And more adapted you've become to a file system implementation, the harder it's going to be to transition to a DBMS. Received on Wed Dec 07 2005 - 15:13:49 CET