Re: Just one more anecdote

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

In other words, pinning it on the data model ignores more or less the entire software development process. 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.

>
> It is very likely that the conceptual data model and surely the
> subsequent logical data model from which the original system was
> developed would not play to the strengths of the SQL-DBMS. As much as
> we might want to think otherwise, even the design of a conceptual data
> model is influenced by the designer's knowledge of the target dbms. A
> redesign of the data model for a SQL-DBMS is likely to both bump
> features and increase complexity -- a harsh one-two punch.

I'll be happy to go head-to-head with you here.

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

Methinks perhaps that you can only appreciate 1NF if you appreciate the above.

Then I boldy state Downs' law (completey w/o proof of course): People find it easy to work with tabular data. 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. Now by extension I would ask why it is that so many people find it so self-evident that the RM is valuable? 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) 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.

A direct consequence of Downs' Law is that the best way to design a system is to go directly to table design. Sit down with all the stakeholders and turn brainstorming directly into table design. As form follows function, the rest of the system will follow the table design, and the development process and tools will assist in that development workflow.

Another point is that the RM is perfectly happy with hierarchies, although SQL decidedly is not. Sigh.

So I bring all of this up for two reasons. First is to state emphatically that your original claim regarding SQL-RDBMS was very unlikely to be true because it considered so little of the world. But my second point is to avoid the unspeakable bad taste of critizicing one view without providing an alternative, so that you may likewise criticize mine. Long live the dialectic!

>
> My conjecture is that downgrading, I mean moving, from a graph data
> model to a relational data model and from a PICK dbms to the SQL-DBMS
> were significant factors in this project failure. I could be wrong, of
> course.

I think that you are sincere and have put your finger on something, but that you have missed that something and have come to the wrong conclusion.

My reading of the project description finds a great deal of drum-beating for the .Net conglomerate, suggesting heavily that the project was driven by political goals, not technical. When this happens it is like sacrificing freedom for security, you get neither. Also, if the project really was politically driven, then it probably was a downgrade.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)