Re: 3vl 2vl and NULL

David Cressey wrote:
> "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.

Agreed.
>
> 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.

I think you said that in a way with which I agree -- was that a mistake? ;-) They cease to be databases by my definition when they do not persist data from one process to a completely separate process. Storage (or persistence for the young 'uns) is a requirement for a database, whether paper-based or electronic.

> Dawn's view, as near
> as I can make it out, is a process-centric view of the service of
> information sharing.

I have no interest in any data that is not ever accessed. The services or API to the stored data is of primarily interest to me. How the data are actually written to the storage medium is of little interest to me.  The model used by a developer (or other end-user) when accessing the data and metadata are definitely of interest to me.

> 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'm not sure what a data sublanguage is, so this might just be a question of semantics. It is the API with which a developer can do CRUD services with the data.

> 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.

Agreed

> 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.

Agreed.

>
> 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.

Agreed.

> 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 don't recall ever thinking of it that way, but I can see why you say that. I am more of an end-user (aka developer) looking to those defining the API for databases to provide me with an API/language/whatever that meets my requirements.

> I
> feel that application programmers are not prima facie competent to design
> databases for the purpose of data sharing.

Application developers (I've programmed a little in the past decade, but not enough to claim to be a programmer, I suspect) are data modelers. They model data for all sorts of purposes: e.g. data entry screens, data collection from devices, printers, databases, file systems, data exchange. I understand that there could be a division of labor where one developer specializes strictly in data modeling for persistence while another specializes in data modeling for user interfaces, for example. If a development team does not have that luxury, then individuals might need to be able to model for all purposes. I still think it is possible for a single person to do end-to-end development, although it requires a number of skills, not all of which will be executed perfectly.

> 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.

A seasoned developer is a data modeler. If the API for the database is good enough, it should not be brain surgery to extend that knowledge to persistence.

>
> And data sharing is where, in my view, you get the bang for the buck out of
> database development.

Absolutely.

> 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.

I don't think that is where the distinction is, although the more developers you have using an API, the more standardized you want that API to be. So you do have a point that in an environment where there are hundreds of developers reading and writing to the same database, it is important to have one team manage the integrity constraints, whether coded in SQL, COBOL, or Pick services. A Pick approach is only "less ambitious" in that it is less work, not in that it provides much else in the "less" category as best I can tell.

>
> What I think Dawn is missing is the big picture about "large shared
> databases".

On the other hand, I think you know that I understand your point and simply disagree with it.

> And I just about concur with "Spight'sLaw": sooner or later,
> you're going to need a DBMS.

Agreed.

> And more adapted you've become to a file
> system implementation, the harder it's going to be to transition to a DBMS.

But it need not be a SQL-DBMS. There are and will be easier to use approaches that do not conform to the Information Principle and include constructs such as lists. Just to bring it around to the subject line, these almost all employ a 2VL rather than a 3VL, thankfully.

Cheers! --dawn Received on Wed Dec 07 2005 - 16:50:41 CET