Re: 3vl 2vl and NULL

From: Frank Hamersley <terabitemightbe_at_bigpond.com>
Date: Wed, 15 Feb 2006 23:10:31 GMT
Message-ID: <HxOIf.8987$yK1.567@news-server.bigpond.net.au>

dawn wrote:
> Frank Hamersley wrote:

>>dawn wrote:

> <snip>
>

>>>Now you are preaching my sermons.  I definitely care about scalability.
>>
>>Who doesn't?  However you seem to be more significantly more concerned
>>with flexibility.  This is strongly evidenced in your writings and has
>>IMO resulted in an incorrect balance derived from inflating the apparent
>>(as you see them) detractions of RM whilst discounting any possible
>>slurs on the MV sphere (which you know and lurve).

>
> I realize I come across that way. I suspect that over the past decade,
> I have identified and talked about more things wrong with MV than with
> RDBMS's.

For my benefit can you identify the top 5 (in your opinion)?

> When talking about data modeling, however, that is one area
> where I cannot leave MV behind unless I can find a better data model.
> That was frustrating given that it is the data model part of the RDBMS
> that was touted from the start and the reason it was supposed to be so
> far superior to other databases. It is less of a mystery to me now
> than when I came here, however.

OK - but to summarise our discussion to date your problem with the RM is the inherent constraints prevent you from having a visually aligned data model that correlates exactly with the user view of the data model as particularly expressed by the UI.

Is this a (relatively) succinct statement of your view?

[..]
> There is some risk you can eliminate, but I'm not sure the risks, for
> example, of bad data or poor programmers (or good programmers sometimes
> producing poor code) can be eliminated with reasonable cost. I do
> think that the lock-down vs. enough-rope-to-hang-themselves approaches
> each have different risks.

Definitely - I prefer the former because it increases transparency by reducing the possibility of a clever type obfuscating the true situation by insisting you "never mind the quality, just feel the length". Yet again a dailywtf demonstrates this sad trait is alive and kicking in the industry.

>>>>Getting the union is the trick.  Where I see the RM
>>>>playing a part is in assisting in retention of the union even as
>>>>evolution occurs.

>
> Is this intrinsic in the RM or part of the lock-down approach? If you
> were to add in ordered lists as a viable type (which I think some SQL
> tools might do?), thereby ignoring the Information Principle and no
> longer using RM, would you lose the feature you want?

RM is to the extent ppl accept and use it is a "lock down" approach. I recall the latest SQL standard does have sets as a domain type - but I'm not sure they are ordered. Regardless, as you imply, to adopt features like those you tendered does weaken the outcome. My response is not to throw out the baby, but prohibit the use of these non compliant features in my shop. Anybody report who thinks differently would find it career limiting first and sayonara soon thereafter!

For the record my pet hates at the moment (but not a comprehensive list at all) are:
a) on delete set null
b) CLR

>>>I think that many people who employ the RM think they are optimizing
>>>the cost of ownership over time where I don't think that is the case
>>>(but I don't know how to prove or disprove it inexpensively).
>>
>>Perhaps because you would use a MV style of thinking in the analysis.

>
> Perhaps, but doubtful. Examples I have given in the past are related to
> changes in the conceptual model for increasing the cardinality or arity
> of an attribute require few changes in schema or applications using an
> MV or XML data model, for example, while they require much more
> significant changes to the RM model and related applications.

I would hold that if such an act proved difficult under the RM then I would first seriously question the requirement in its own right. For instance a business request to support recording of a text value "NIL" in the Balance when it is currently a numeric attribute, simply so it could be reported as that (rather than 0.00) on a statement is surely fatuous. This is a rather obvious example, but less clear cut cases the RM acts like a canary in a coal mine! This nature survives your (sic) initial project activities and your continued involvement unlike an MV situation where the sum of the cults of the individuals will accrete. Of course this negative trait can be mitigated by skillful management, however the Peter and Dilbert Principals will prevent this arising.

>>Given its propensity to allow the mind to wander where ever it likes
>>perhaps the analysis would never be convinced it is at a conclusion?

>
> It seems the opposite. Because you can rather easily change things
> later, there is more inclination to "jump in" so it works very well
> with an agile methodology. I recall when a CMM (capability maturity
> model) methodology person came into a PICK shop (of ~200 developers) at
> a high level and did some applecart upset, but didn't last long.

This simply confirms what Canute discovered. His goal may be correct but his method not. That doesn't mean it is unachievable as the Dutch have showed.

> MV developers are inclined to prototype in the target environment and
> then migrate that into the solution. I recall this being a no-no from
> at least the early 80's so I was surprised to find this happening in
> '89 when I landed as a manager in a PICK shop and even more surprised
> to find I was encouraging it in no time. This flexibility carries on
> even once deployed. Is it possible to get the features you are looking
> for along with this type of flexibility?

Yes - but it must be self imposed.

> I'm cutting it short here again due to time and since I've been chided
> for length. Cheers! --dawn

Cheers Frank. Received on Wed Feb 15 2006 - 17:10:31 CST