Re: *****SPAM***** RE: Differences between Oracle and Progress, actually starting point for considering any migration from Oracle to anything else...

  • From: ryan_gaffuri@xxxxxxxxxxx
  • To: niall.litchfield@xxxxxxxxx, mark.powell@xxxxxxx
  • Date: Wed, 21 Mar 2007 15:56:09 +0000

I remember talking to our progress DBA. I don't think it has the kind of metric 
collection that Oracle has. Progress is a real niche market. The gusy there 
claimed it was big in the manufacturing sector. If you are interesting in 
progress just as something new to learn there is a pretty popular Progress 
forum/website out there somewhere. 

The progress developers swear by it. To be fair our progress developers 
produced. It seemed like they were able to develop code much faster than the 
java team since it was a 4 GL environment and they had to write alot less code. 

However, since progress is such a small market the odds of you working on a 
team that is using it is pretty small. Progress has actually developed an 
Oracle engine where developers code in progress, but the middle tier generates 
sql. Probably to try to expand their market space. It was pretty difficult to 
figure out where bad sql came from since when you go back to the code its 
basically written as a loop structure. 

I really don't know how many high end systems are run on Progress. Since the 
market was so small Progress developers seemed to move around the country going 
from project to project. 

-------------- Original message -------------- 
From: "Niall Litchfield" <niall.litchfield@xxxxxxxxx> 

On 3/20/07, Powell, Mark D <mark.powell@xxxxxxx> wrote:

While using a physical stopwatch is a valid end to end timing method
(from customer enter to response), this method definitely lacks 
precision for timing individual database operations.  I can see some
humor in running across this recommendation.

I tend to agree, whilst it's an absurdly amateurish approach, it does at least 
have the benefit of doing the right thing, the section this comes from 
essentially boils down to

1) Determine the transactions that matter to your business. 
2) Measure the response time
3) create baseline
3) monitor against baseline
Now that is clearly ripe for maturing into a method R type approach. The 
measurement device is inappropriate and the granularity appears to be the 
entire transaction, but at least it is the right general idea. 

Unfortunately the lack of granularity is probably responsible for the next bit 
that starts

"Always analyze problems starting with the slowest resource and moving to the 
fastest. Thus, the first place to start is disks, then memory, and finally CPU 
Hmmm - because I've never seen a system starved of CPU with idle disks, no sir 
not me. 

Mind you IIRC this thread started with a question about the relative merits of 
Oracle and Progress for some existing systems, it seems to me that in this 
context the right place to start is not relative performance, but wether the 
application will run at all. My guess is that many/most Oracle apps will not 
run without considerable effort on Progress and vice-versa - and the ones that 
do are probably platform agnostic and perform badly everywhere anyway. 

I'd much rather take the point of view that we are in the business of 
supporting applications, not databases and that the right database choice is 
driven by the application which in turn is driven by business need. A bit like 
the reason that so many corporations run windows - not because of a love of 
microsoft, but because the applications that they need run on it. 

Niall Litchfield
Oracle DBA 

Other related posts: