MySQL v. PostgreSQL, continued, was: Microsoft Access - two questions

Bill Sconce sconce at in-spec-inc.com
Tue Jul 31 12:38:14 EDT 2007


On Tue, 31 Jul 2007 10:39:32 -0400
Ted Roche <tedroche at tedroche.com> wrote:

> >Paul Lussier wrote:
> 
> > It is lacking features[1][2], and I've certainly seen plenty (if not most)
> > uses of MySQL completely abuse it to the point where the "developer"
> > completely missed the "R" point RDB[3].
> 
> Most programmers are amateurs. Even the really, really good ones.
> Business application programmers follow the same normal curve as most
> everything else: few really, really good ones, few really, really bad
> ones, but the bad ones leave such memorable disasters behind them!
> 
> More fuel for the fire... Josh Berkus blogs,
> 
> "What is does show is that PostgreSQL and MySQL are very, very close in
> performance today and the outdated belief that MySQL is somehow multiple
> times faster than PostgreSQL is dramatically misplaced. Users should be
> picking a database based on which specific performance features, and
> other features, they need in their database and not out of some ignorant
> assessment that "Database X is way faster." That's pretty much been true
> for years, but the very close benchmark results shows that pretty clearly."
> 
> Source:
> http://blogs.ittoolbox.com/database/soup/archives/benchmark-brouhaha-17939
> 
> Competition is Good.



One symptom which indicates that programmers are amateurs is that they
prematurely optimize.

In this case, a concentration on performance, as though it were the only 
question.  In the professional environment, performance is only one of 
several, or many, considerations.

In aviation, for instance, there has been over the years a succession of
"new technology" in engines, repeated again and again.  "More HP!"  "Faster
cruise speed!"

Also repeated again and again: sober experience from deployment.
Heat load.  Reliability.  Holes in pistons.  (A little thing like that
at 8,000 feet can ruin your whole day.)

So real engineers laugh at the "10 more horsepower" crowd.  It's the same
in power-plant design, the same in refineries, the same in architecture,
the same in bridge building.  (Bridges give us some EXCELLENT examples of
what happens when an engineer goes a little bit amateur.  You've probably
seen a video of the Tacoma Narrows bridge coming apart.)

IN THIS CASE (databases) it's not professional to concentrate on performance
as though all the other considerations have been proven to be equal.  They
have not.

For one example, the difference in licensing, and in proprietariness or 
potential proprietariness(*) has not been established.)  Only an amateur
would feel satisfied at "10% faster" when the customers' real exposure may
appear two years from now when one product or another is withdrawn from
the market.(**)

I'm not saying any of those other things will happen.  It's only that real
engineers recognize things which *might* happen and factor them into the
work they do for their clients.  (Like winds and resonances for a bridge
design.)  The amateur has the luxury of concentrating on the "fun" things.
Like performance.

also_from_the_heart'ly yrs,

Bill


(*) potential proprietariness - read: whether a large corporation might
buy out the principal sponsor of the project, or enter into a "patent
agreement" with the principal sponsor of the project.  Whether the
principal sponsor is a commercial entity or not can become an issue.
(Think of Novell.)

(**) withdrawn from the market - read: whether a large corporation might
buy out the principal sponsor of the project with the express purpose to
leave customers with a "migration path" to the obvious remaining "choice".
(Think of Blackboard and WebCT.)


More information about the gnhlug-discuss mailing list