Re: How to create a DBMS from scratch?

The world rejoiced as hidders_at_REMOVE.THIS.uia.ua.ac.be (Jan Hidders) wrote:
> Emmett wrote:
>>Sometime in 1996 or 1997 I recall reading in the Wall Street Journal
>>where Oxford .. Oxford something ... some gigantic health insurer
>>based in Chicago (I think) migrated away from Pick to a
>>relational database (I think Oracle).
>>
>>It was a total disaster precisely because so much of what was
>>done in Pick couldn't be done at all using a relational DB.
>>
>>Since Oxford was growing outrageously quickly they weren't
>>able to bill all their patients. It was common for doctors to wait
>>six to eight months for payment.
>>
>>Oxford wasn't able to bill many of it's patients because
>>their database system was hosed.
>>
>>The entired deal parciptated some big event - like Oxford going
>>out of business completely - or getting in trouble for having
>>merged with some other insurer and messing things up.
>>
>>Great story. I wish I could remember it better.
>
> Me too, because the details matter here. It is trivial to find a
> mapping from the Pick data model to a relational model, but the
> question is what your requirements are. So it all hinges upon the
> question how good your system analysts, who have to define this
> mapping, are. If these people don't know their job you can even get
> into the same problems when moving from an Excel-based application
> to a database-based application. That doesn't prove that Excel is a
> better database.

More than likely the /real/ problems were business problems. They almost always are.

If a big consulting firm was involved (often the case!), the disaster could have readily still occurred even if they stayed with Pick, as the firm would certainly not have centered the work around "how does Pick work?" (any more than it is likely that they centered the /actual/ work around "how does Oracle work?"), but would rather have the scope of work based on the question: "What is Our Methodology?"

Throw together:

1. A Methodology that doesn't fit the application,
2. Account executives that are happy so long as they are billing,
3. An attitude that technical problems aren't all that important, and you can get a /huge/ disaster that cannot legitimately be tied to any particular piece of technology.

<http://www.itworld.com/Man/2680/CWD001030ITSnafus/> points at some of the notable disasters. All of them are essentially /project/ failures, not /technology/ failures.

-- 
(concatenate 'string "cbbrowne" "@acm.org")
http://www.ntlug.org/~cbbrowne/
"Let me get  this straight: A company that  dominates the desktop, and
can afford  to hire an army  of the world's  best programmers, markets
what is arguably the  world's LEAST reliable operating system?  
What's wrong with this picture?"  -- <frist_at_cc.UManitoba.CA>