Open Source for mission-critical systems (slightly OT)

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Fri Jun 3 17:27:48 UTC 2005


On Fri, Jun 03, 2005 at 12:23:21PM -0400, Andrew Hammond wrote:
> If you have a trivial problem, then I expect that a trivial solution is
> in order.

Most web sites are rather trivial when you get down to it.

> And ran into performance problems. What a suprise.

The only performance problems was when too much was asked of the
database server.  The less we relied on it to do, the better the
performance of the whole system became.

One perforamnce problem initially was postgres's terrible handling of
subselects (and initially the lack of support for them).  That improved
with new versions of postgres which sped up queries a lot.

> This is exactly the kind of incorrect assumption that junior developers
> make. Stored procedures are an enormous win when you're trying to solve
> performance problems. This has been demonstrated so often it's not even
> seriously debated anymore. Obviously I'm talking about business logic
> here, not presentation logic or raw processing.

I have used postgres procedures to convert data, since nothing external
could possibly compete with it in performance.

> Designing for database independance by definition means accepting the
> subset of the intersection of functionality across all databases you
> intend to support as well as the set of the union of all limitiations
> and bugs across all databases you intend to support. If you're willing
> to accept a database as useless as that, then your application would
> probably be better served by not using a database at all. Furthermore,
> no one person has sufficient expertise in more than perhaps 2 databases
> to know what the limitations and bugs really are.

Well we found the SQL features in postgres rather useful, and had no
intension of supporting mysql at the time (it lacked too many useful
standard features of SQL) or any of the other limited SQL support
databases.  Moving up to a commercial database with a full SQL
implementation would not really be a problem of course.

> In the case of your tires analogy, I expect that you'd spend a hell of a
> lot more time desiging the rest of the car. I also expect that cars are
> typically designed with only one engine in mind.

Most cars are designed with multiple engines in mind.  Those engines are
also often designed to be used in multiple cars.  Doing anything less
would not be cost effective.

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list