Re: 3vl 2vl and NULL
Date: Thu, 02 Feb 2006 07:41:25 GMT
Message-ID: <FIiEf.233626$V7.16324_at_news-server.bigpond.net.au>
dawn wrote:
> Frank Hamersley wrote:
>>dawn wrote:
[....]
>>>This is where there could be some measurement. My hunch is that there >>>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.
I guess in the MV world performance is more likely to be linear and remain so. This can be reassuring to management but the downside is there is limited scope for a "cheap correction" as described in the WTF to bring about a huge improvement. Of course you could hack into the code but then "not broke" resistance will need to be overcome.
> Can you point me to some entries at
> http://www.thedailywtf.com/ that talk about project failures with
> MV/Pick systems?
No - my visits to the site are infrequent and haphazard!
> 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.
I have only one first hand observation - a financial accounting system that could not accurately compute simple interest on a call balance. It used to drive the accountants absolutely nuts but the Pickies couldn't and wouldn't find a way to correct it - in their minds it was only a few cents here and there - never more than $1.00 per annum so why the big fuss? Why spend lots of time and money hacking the system for a few $ when they couldn't be sure what else they would bust re-engineering the accrual mechanism. Eventually the Treasurer got jack of their attitude and bought an external package solution that was SQL based so he didn't have to keep explaining to the board why the organisation routinely got slagged by its somewhat captive customers about its capacity to calculate simple interest. Some of the Pickies subsequently got a Darwin award for their troubles!
>>>However, then folks will argue that you pay the price down the road in >>>MV (which I do not see to be the case).
My anecdote confirms at least 1 contra example - there is no empiricism though. My strike rate is 100% but you will argue even accepting my case it is still close to 0%. This is reasonable - my purpose is to illustrate MV does not preclude failure.
>>> 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. >> >>>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 >>>"Maiden Name" attribute (or whatever is deemed politically correct now) >>>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.
How would retrospective states be analysed in your stack oriented record?
Consider a model where a "Person" was designated as having a "Rank" and
that the Rank affected automatically generated "Correspondence".
Say an operator of the model incorrectly changed a Persons Rank from
"First Officer" to "Captain" and they did not rectify the error for
several days.
How would you using the MV model alone determine the number of cases and the parties affected by an event where Correspondence for the eyes of Captains only was forwarded to a First Officer?
I expect you would have to code it, and if insufficient data had been retained by the designer it might prove impossible! This also the case for the mainstream SQL engines today - if it is not designed in it won't be feasible.
However it is an active area of research in academia at least to build
integral temporal support into the SQL standard. Progress to date has
been very limited based on my review of the papers published so far.
>>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
Whats the alternative? Something like MV standards - ie only those that any particular developer feels like instantiating in their code? Sounds like more anarchy to me! :-) Reaching that state of affairs would be a Bad Thing (TM) IMHO!
Cheers,
Frank.
Received on Thu Feb 02 2006 - 08:41:25 CET