Re: 3vl 2vl and NULL

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

> >>>I'm afraid I don't have magic, just finesse.
> >>
> >>I have no magic either - but I subscribe to the "don't go there"
> >>approach so I can deploy my skills on certain tricks rather than maybes.
> >
> > Every solution has it problems. You must do risk assessment
> > throughout, no matter what tools and techniques you choose. You might
> > be mitigating different things, but you are not eliminating risk.
>
> That is not axiomatic at all - it is possible to eliminate risk by
> deliberate choices. I disagree that you are simply "shuffling
> deckchairs" although there may still be some on the deck regardless.

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.

<snip>
> >>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?

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

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

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?

I'm cutting it short here again due to time and since I've been chided for length. Cheers! --dawn Received on Wed Feb 15 2006 - 17:10:51 CET