On Tue, 31 Jul 2007 10:39:32 -0400 Ted Roche <[EMAIL PROTECTED]> 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.) _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/