Open Source for mission-critical systems (slightly OT)

[Andrew Hammond]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Sorensen wrote:

> Sometimes treating a database as a very clever filesystem and
> nothing more is a good idea. 

If you have a trivial problem, then I expect that a trivial solution is
in order.

> Sometimes you do something more advanced where you want to
> enforce table relations and data integrity, in which case you have to
> start using more features, and portability takes a hit.  We wanted to be
> portable to another database at the time, and had no real need to put
> the logic in the database so we avoided it.

And ran into performance problems. What a suprise.

> I do know futureshop's prior provider of photo storage died because they
> couldn't scale past a few thousand users, and they had put all the logic
> into a MS SQL server.  They were running on an 8 cpu intel server before
> they finally died out just trying to get the database to handle the
> requests fast enough.  It is much easier to put the logic into the
> scripts of the web server and let the database just handle queries

It's certainly easier to develop.

> if
> you want to be able to scale to a lot of users without using a database
> that can in fact run multiple servers at a time sharing the load.

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.

> If postgres could have done that at the time, we would probably have used
> it that way for some things.
> 
> As for the junior developer thing, well I think you are wrong.  I think
> designing things for one database when you don't have to is like making
> tires that only work on one brand of car. Might save you a little time
> in some cases and work slightly better, but you sure limit your
> potential users in many cases.

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.

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.

- --
Andrew Hammond    416-673-4138    ahammond-swQf4SbcV9C7WVzo/KQ3Mw at public.gmane.org
Database Administrator, Afilias Canada Corp.
CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCoIP4gfzn5SevSpoRAsD1AJoDzSNR3yvsO9rhzitZHs5CoOVsfACgjMjg
gtLU6V1w2XabcxopCPGKilA=
=9JUF
-----END PGP SIGNATURE-----
--
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