Re: 3vl 2vl and NULL

dawn wrote:
> Frank Hamersley wrote:

>>dawn wrote:
>>>Frank Hamersley wrote:
>>>>dawn wrote:
>>>>>Frank Hamersley wrote:
>>>>>>dawn wrote:
>>>>>>>Frank Hamersley wrote:
>>>>>>>>dawn wrote:
>>>>>>>>>Frank Hamersley wrote:

>>>To some extent, perhaps (somewhat similar to XML developers thinking in
>>>strings), but my reason in this case is that although you might cast to
>>>another type (even on the way in after testing for compatibility), all
>>>data input through a UI can be handled as a string, the empty string
>>>being one such.  The string could be seen as the top object for data
>>>entry, with all other types inheriting from it.  A number is string
>>>input that can be cast to a numeric type, for example.  (I realize this
>>>might be heresy to some)
>>
>>OK - my view differs in that the bit is the "top object".

>>>>>>I disagree - there are measurable gains to be had in adopting the RM for
>>>>>>the storage engine that,
>>>>>
>>>>>Can you point me to some emperical data that indicates that?  And even
>>>>>if that were the case, are there corresponding gains to making the RM
>>>>>the interface between dbms and humans (developers)?
>>>>
>>>>I have no empirical data (for or against).
>>>
>>>What are these "measurable gains" then?  What do they measure? Who has
>>>done such measuring?
>>
>>First, the most obvious gain is a repeatable capability to consistently
>>disseminate and/or interrogate a large and complex dataset amongst many
>>people all with varied interests and in so doing avoid the need to
>>inculcate them with all the various nuances a 2VL programmer might dream
>>up to persist each item of data.

Perhaps so - the fact that it is feasible at all is reassuring!

>> After factoring in a life cycle and
>>unavoidable changes in staffing these nuances can become debilitating.

In the strictest sense there prolly isn't any. Nobody in IT conducts blind trials or uses statistical methods to assess outcomes - about the only quotable statistics seems to be the project failure rate exceeds 50%!

>>The rigour inherent in the RM goes some way to reducing this risk (of
>>course it is not foolproof).

And conversely I accept rigour can be established in the 2VL space - but it requires compliance from the developers!

>>Of course the extant business rules buried in the data itself are an
>>unavoidable cost of entry to the club - that is a given regardless of
>>the RM's involvement.
>>
>>Secondly, the measured aspect as inferred above is the linear aspect of
>>continuing to deal with the data, rather than an unquantifiable risk of
>>non-linear cost/effort in a less rigourous implementation.

Stored procs are not part of the RM (at least in my view). There are benefits in having them, but they are mainly operational in my view.

>>Thirdly I have done the measuring over the last 25 years!

Anecdotal. The only empirical aspect is this black duck is still in business...that said lots of bad IT types are also still in business too!

>>There are
>>other independent sources however - one I find quite humorous (but a sad
>>comment on IT nonetheless) is visible at http://thedailywtf.com.

>>In all
>>my casual viewings of the material on this site, by far and away the
>>predominant examples are from 2VL exponents or as in todays case 2VL
>>types trying to railroad an SQL/RM database.
>>
>>
>>>>On anecdotal terms however
>>>>and relating to some of the commonly held (as far as I believe) precepts
>>>
>>>Yes, there are some such that need fixin'
>>
>>Which other precepts and what needs fixin' is also eminently debatable!

>>>>of good IT such as independence (separation of logical and physical) and
>>>>simplicity (some will dispute this of course)
>>>
>>>I tend to want things simple for me (and those around me) in contrast
>>>to insisting everything be as simple as possible for the developers of
>>>my tools or for the tools themselves.
>>
>>My view is less self centred - I always look to maximise the long term
>>corporate benefit even if it is more work for moi at the outset!

Cheers, Frank. Received on Tue Jan 31 2006 - 13:34:05 CET