Re: To CASE or not to CASE

Regarding these ideas:
>The two schools of thought here regarding CASE (excluding financial issues)
>1) Use CASE as it will help the inexperienced team produce a usable DB in a
>shorter amount of time.
>2) Don't use CASE as the manual work will give the team a better
>understanding of underlying design/development skills.
 

>FWIW: If you are just starting out with limited experience, you will be far
>better of without Case (anyone's, not just Oracle's). This is not because
>the products are poor or anything, but you should learn how to do it without
>so you understand what CASE is doing later on. If you don't know the basic
>REAL well, case will just make the job more difficult. IMHO

My 2cents:

Any team designing a relational database, first needs to understand database design, which means understanding entity relation modelling. If your team doesn't know how to do this, you will create a tremendous amount of downstream work.

After data modelling, you have to denormalize in order to meet performance requirements. To understand these requirements, your team should understand functional modelling and event modelling.

The big problem in using CASE tools is in learning the techniques. You can't save any time, long term, by designing a system without knowing how.

I suggest learning the techniques, use CASE tools properly, then build a database you can live with without hating later on.

BIAS Announcement- I am a CASE and Data base design consultant. I do this kind of work because I believe it is the best way to create a system.

Solution Engineering Inc.
1290 Osage St North
St Paul Mn 55117-4062

  Bob Treumann                          email:  btreuman_at_empros.com
  phone: (612) 553-4346                 (612)-489-4960 home