Re: 3vl 2vl and NULL

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Thu, 08 Dec 2005 01:06:18 GMT
Message-ID: <eGLlf.14136$ea6.10516_at_news-server.bigpond.net.au>


dawn wrote:
> David Cressey wrote:
>>"dawn" <dawnwolthuis_at_gmail.com> wrote in message >>
[..]

> I have no interest in any data that is not ever accessed.

I presume you meant to say any underlying infrastructure, as a distinction from application data and the bridging metadata. IE. stuff that is not exposed to the A/P.

[..]

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

Personally I reckon the majority of A/P's and even DBA's are barely, if at all, competent - but then my views on the state of this "profession" have been made in this place before.

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

I resemble that remark! In my defense I find and fix (most of) my own bugs!

[..]

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

[..]

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

Without wanting to be being seen simply as a self flagellating masochist, "easier" is rarely IME better. In the case of the vast majority of so called practitioners it basically leads to sloppiness with their counter refrain of "I will always be able to come back and fix it if a problem arises because it is easy to make a change/fix".

This is a hallmark of the fair-weather sailor and you should not venture past the Heads with them, and certainly don't want to do a Sydney-Hobart! For all the smart types Bill has employed, this over-arching attitude has clearly manifested itself in Spades when assessing the legendary reliability and security of their products. That said you can still "work smarter, not harder" even if the tools you are handed appear limiting.

"where's my shifter *" (not) Frank.

  • an adjustable spanner that fits all heads and burrs them indiscriminately to the point they can no longer be undone!
Received on Thu Dec 08 2005 - 02:06:18 CET

Original text of this message