Re: Just one more anecdote
Date: Tue, 02 Aug 2005 19:55:22 -0400
Message-Id: <jld5s2-u63.ln1_at_pluto.downsfam.net>
dawn wrote:
>> dawn wrote: >> >> > I'm sure there are numerous factors playing into the fact that the >> > system touted in this MS Word document >> > >>
http://www.microsoft.com/resources/casestudies/ShowFile.asp?FileResourceID=1611
>> > >> > has been discontinued and written off to the tune of $67 million in s/w >> > development as seen at >> > http://biz.yahoo.com/prnews/050721/clth018.html?.v=16 >> > >> > This is yet another instance where a legacy system written with a PICK >> > (in this case), MUMPS, IMS, or other pre-relational database product >> > didn't successfully make the jump to a SQL-RDBMS. >> >> I may agree if we phrase it more precisely: >> >> "This is yet another instance where a _stable_ system ... did not >> successfully make the jump to a completely new data model, software >> architecture, hardware architecture, operating system(s), set of >> programming languages, and (most likely) much younger and less >> experienced body of programmers, with an almost certain lack of serious >> input from the designers of the original system."
>
> I'll agree with that, of course.
>
>> In other words, pinning it on the data model ignores more or less the >> entire software development process.
>
> If I pinned it on that, I would agree. I have no doubt that are many
> variables. Project & process issues play a significant role in most
> project failures. I forget the author who rather recently wrote that
> in spite of such issues, more s/w projects still fail for reasons of
> performance (as in speed) than any other issue.
>
> I don't know why it failed, but I have a hunch (and it definitely could
> be wrong) that the data model was a factor. Your hunch may be
> different and you may completely discount my hunch. I would love to be
> able to figure out an experiment that would shed light on this
> question.
This weakened assertion, that the data model "could be a factor" suffers from the same problem as the original stronger statement, it is floating free of any context or perspective.
Because it is true that any architectural element "could be a factor" in a project's failure, and it is moreover true that any number of human factors "could be a factor" in a project's failure, it is downright misleading to pick one out and trumpet it as worthy of attention. I have suggested the political motivation, and my "hunch" comes right out of the documents you provided, what is the source of your hunch, and can you stick to the materials provided?
>
>> I'll be happy to offer anecdotes surrounding >> every other item I've listed. But the statement as you wrote it cannot >> be taken seriously.
>
> You don't have to take it seriously, I do. I'm on a quest to determine
> whether my experience of TCO for non-SQL-DBMS tools being significantly
> lower than for SQL-DBMS's is a fluke or has some basis. It is so hard
> to figure out how to get emperical data (you can't even compare tps
> between SQL and non-SQL dbms tools as best I can tell) that I've been
> reading up on theory. I also keep an eye open for project failures, in
> an effort to more hints.
Please name a project you were involved in that justifies your claim to have lower TCO experience, perhaps you may want to do that even in another thread under a suitable heading.
But you cannot list the project in question because there is no evidence the data model had anything to do with it.
>
> What I find interesting is that people who have not worked with both
> data models are so certain that the data model had nothing whatsoever
> to do with the project failure. I would like to have such certainty,
> but until then I'm stuck with hunches.
How do you know I have not worked with both? Well OK, I haven't :)
But here you are doing what you accuse others of. You have stated many times that you find Pick satisfactory, are looking for a persuasive argument of the superiority of RM, and have not found one. In other words, you are happy where you are. For many in this group the situation is reversed, we are happy where we are in the RM (or Quasi-RM) and have seen no persuasive arguments that we should move anywhere else.
Therefore if we are not qualified to judge, neither are you.
<SNIP>
>
>> First, the RM is perfectly suited to the task of CRM. This is because >> the relation (or table) gives us the mechanism for storing details about >> like items, while the miracle of the foreign key allows facts in one >> relation to >> be logically connected to facts in another. The discipline of >> normalization allows a well-designed RM database to have the amazing >> feature that "there is a place for everything and everything in its >> place."
>
> yawn ;-)
???
This is very telling. I've never doubted your sincerity before but now I wonder. The fundamental task of the database theorist is to find a way to store facts. The RM has this in a wonderful way. Why do you scoff?
>
>> Methinks perhaps that you can only appreciate 1NF if you appreciate the >> above.
>
> I thought the group largely agreed that 1NF was meaningless in the RM
> at this point. What is your def of 1NF?
Not me. I participated little or not at all in most of the 1NF arguments because I am old-fashioned and find Codd's original 1NF to be just fine. If you want a list, put it in a child table, that's what they are for.
>
>> Then I boldy state Downs' law (completey w/o proof of course): People >> find it easy to work with tabular data.
>
> I'll agree with you on that.
How can you agree with this and give me a "yawn" on my description of the benefits of the RM? Are you an MBA? (ducking)
>
>> I think I've heard you mention Bible >> study before, so I'll go at this one with a religious argument. >> Question: what is the simplest explanation for the fact that all human >> societies have religion, and that all human societies believe in a >> creator that is outside >> creation? Answer: The simplest answer is that their belief is true. >> Everything else introduces complications to protect a pre-conceived idea, >> and the complications pile up like epicycles in Ptolemy's solar system.
>
> I enjoy reading apologetics and think it a brave sport, but you won't
> catch me going that route.
>
> You are using "the simplest model is the best model" and I don't buy
> it, although I don't dismiss it as useless.
>
> Are you a Unitarian? It certainly provides a simpler model for God
> than any Trinitarian view, right?
Nope. The simplest correct model is the best model.
I am a Trinitarian because that view is the simplest explanation of what we
know about and have experienced of God. Unitarianism is not likely to be
correct because it must ignore so much of the story to get itself
comfortable, and so it does not matter to me how simple it is.
But to the matter at hand, one of the simplest explanations for the widespread acceptance of the RM is that it is useful. Just as in apologetics, this simplest explanation must at least be considered, even if it is found later to be false (as in the 4 elements). It seems to me you refuse to consider the simple possibility that the RM is more useful than you think, because you cannot appreciate the simplest things about it.
>
>> Now by extension I would ask why it is that so many people find it so >> self-evident that the RM is valuable?
>
> Hey, even I find the RM valuable. I certainly appreciate the set
> operations, for example. I'm looking for biggest-bang-for-the-buck
> approaches, not just any one that might be valuable.
What do you mean? How is it useful?
>
>> The simplest answer is that the RM >> really is valuable. I also state for the record that your insistence on >> non-atomic data (ie, breaking 1NF)
>
> that answers my prior question -- so you are still in the camp of 1NF
> including no repeating groups, right? That is an area that I think by
> now we have covered with very logical detailed analysis and with
> somewhat general agreement that 1NF, as we knew it, is now dead in
> theory, even though not in practice. You disagree?
The wonderful thing about this free world of ours is that I can do what I want. Since I can put repeating groups into child tables and query them there, I see no reason to represent repeating groups by some other mechanism as well.
>
>> is an epicycle in the Solar System, >> meaning it is a complication introduced to try to fix a basic >> misunderstanding of how things are put together.
>
> Recognize that I'm talking about the logical model not about how things
> are put together. What is the API? Can we talk about a human being as
> a whole or must we partition it into smaller components?
>
>> A direct consequence of Downs' Law is that the best way to design a >> system is to go directly to table design.
>
> Again, I wish I had your clarity on that one.
<SNIP>
>
> My claim was that this was another anecdote with a similar pattern to
> many others (but surely there could be other threads of similarity in
> them, such as those you suggest). My conjecture was that the data
> model change was a factor. It sounds like you are now saying it is
> "unlikely" rather than "cannot be taken seriously" so we are getting
> somewhere ;-)
....and as I said above, your conclusion in this case is clearly pre-conceived. It has nothing to with what was actually written. If you read the documents you would get a very different story. Whether or not you like .Net, one clear concept coming through is that Reynolds tried to build a huge system on a deadline with unfamiliar tools. Can you say "triumph of hope over experience?"
This throws into doubt your entire conjecture that there are "many others" where data model was a factor. If you could come to such a clearly irrelevant conclusion on this story, can we believe that the data model was a factor in any of the other anecdotes in your portfolio? How many of them will turn out, upon examination, to have some glaring flaw that has nothing to do with the data model? All of them? Half? The burden is now upon you to provide the first story where the data model was the culprit.
Now I ask with all respect, why is it that you are so fascinated by the RM that you keep coming back? Are you like the atheist that never stops talking about religion, hiding a desire behind a criticism?
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Wed Aug 03 2005 - 01:55:22 CEST