Re: 3vl 2vl and NULL

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Tue, 31 Jan 2006 12:34:05 GMT
Message-ID: <1PIDf.232261$V7.48785@news-server.bigpond.net.au>

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

>
> All the bits I've seen are single-bit strings ;-) I do make a
> distinction between binary MIME types and that which can be entered via
> a standard keyboard (roughly speaking). Query languages, for example,
> operate quite differently on text than on pictures or songs.
>

[..]

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

>
> Now that has GOT to be tough to measure.

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.

>
> I've worked with plenty of systems that are not based on the RM with
> code > 20 years old and counting. So, this measurement, too, could be
> difficult to quantify. I've looked at possibilities for what might be
> quantifiable and nothing looks very straight-forward. I know I don't
> have emperical data related to bang for the buck or any other metric
> for non-SQL or non-RDBMS compared to SQL-DBMS's, but I sure have seen a
> lot of claims about how the RM has been shown to be superior to all
> other models. You just claimed that there were measureable gains with
> the RM. I'm just wondering what these measurements are and how I can
> duplicate whatever experiment these come from.

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

>
> Agreed on both counts.

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.

>
> If all code associated with SQL-DBMS systems were strictly SQL, then
> perhaps one could argue this. However, it appears to me that SQL-DBMS
> systems still have stored procedures and other code associated with
> them for UI's and other processes. So how can you measure this gain
> and related risks?

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!

>
> Actual measurements you can share or anecdotes like mine? It isn't
> easy to get beyond anecdotes and we each have different experiences.
> Can we collect meaningful data with a reproducable experiment?

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.

>
> That's a new one for me--I took a quick peek, will look more later.
>

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

>
> Undoubtedly
>

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

>
> OK, I'll give you that one. I happen to be a one man (zero man, to be
> precise) company right now, but I'm interested in how to improve
> conditions for software developers in order to maximize the long term
> corporate benefit.

>
I always thought when considered in string form ("wo"+"man") that you avowed multitaskers contained 1 regulation "man" per Brooks MMM and a bonus "wo" to perform those other jobs :-)

Cheers, Frank. Received on Tue Jan 31 2006 - 06:34:05 CST