Re: 3vl 2vl and NULL
Date: 31 Jan 2006 17:48:27 -0800
Message-ID: <1138758507.008662.269720_at_g47g2000cwa.googlegroups.com>
Frank Hamersley wrote:
> 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:
> >>>>>>>>>>dawn wrote:
> >>>>>>>>>>>Frank Hamersley wrote:
> [....]
> >>>>>>>>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!
> >
> > How do you know this to be a fact?
>
> Allowing for Nietzsche et al existentialist risk in my assessment -
> simply because they keep loading me up with new work after I complete
> each assigned task.
>> > This is where there could be some measurement. My hunch is that there
> >>>>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%!
> >
> > are fewer project failures in the MV world than in the SQL-DBMS world.
>
> The WTF presentations suggest otherwise, although as Murphys Law would
> have it todays gem is SQL related!
I checked and, yes, this is a typical SQL problem that is rare in the MV world. Can you point me to some entries at http://www.thedailywtf.com/ that talk about project failures with MV/Pick systems? I can certainly think of incidents and project failures with attempts to combine Pick and SQL, but would like to read some anecdotes about major project failures where no SQL was in the mix.
> > However, then folks will argue that you pay the price down the road in
> > MV (which I do not see to be the case). Measurements would need to
> > measure the total cost of developing and maintaining systems, but also
> > some measure to ensure the systems are effective for the users.
>
> Yup - but IT isn't about waiting around for epidemiological studies to
> complete.
>> > "Maiden Name" attribute (or whatever is deemed politically correct now)
> > I'll go out on a limb and say that it is unlikely that a development
> > team working with a SQL-DBMS tool would end up writing the same system
> > from the user perspective as a team working with an MV system. The
> > data modelers for the SQL-DBMS tool will work to avoid multivalues so
> > they don't have to form new tables for short lists that don't seem too
> > important, for example. I've seen more FormerNames fields in MV
> > systems, collecting all former names as they become such in cases where
> > it would not be warrented in a SQL-DBMS system -- a single-valued
> > is more likely.
>
> Interestingly your example would be a non-event if support for the "time
> varying" (temporal) aspect of Codds laws were provided in the various
> main stream SQL implementations.
Yes, and I'll grant that it might be a better approach than the one-at-a-time, pick and choose fields about which to keep a history. However, the "current value on top" pattern is used repeated in Pick and works well for end-users.
> I guess temporality will never become
> integral in the non RM space, and at the current rate of progress in RM
> research not in the SQL standard very soon to boot!
I don't think that any future SQL standards are likely to be very relevant, do you? --dawn
> [..]
>
> Cheers, Frank.
Received on Wed Feb 01 2006 - 02:48:27 CET