Re: Which SQL is the best for servers?

From: The Natural Philosopher <a_at_b.c>
Date: Mon, 16 Feb 2009 07:31:41 +0000
Message-Id: <>

pg wrote:
> I am involved with a SQL server project. The server would be used in a
> very heavy duty environment, with hundreds of thousands, if not
> millions of database enquiries per minutes.
> The server would run Linux or one of the BSD variant, with at least
> 32GB of RAM. We are not very certain of the hardware specs yet because
> we haven't decided on which SQL to use.
> I know that Oracle, MySQL and PostgreSQL are all designed for heavy
> duty uses.

I wouldn't say that at all.

Muh as I love Mysql, its not likley that a basically freeware project naintained out of love is ever going to compete with a real heavyweight like oracle from a serious and large company whose life blood depends on it not failing.

> And I checked all available online resources for a SQL comparison and
> all I could find is some articles dated 2005 or so !
> So, here's my questions:
> 1. Are there any recent SQL comparison article available?
> 2. Since the server may come with only 32GB of RAM, which SQL can run
> the "leanest" - that is, not a memory hog?
> 3. The server might also become a web-server, which SQL can tie itself
> to the Web-based enquiry they best?
> Please give me your suggestion / opinion. Thank you !!

Look a php/apache/mysql/linux solution is a great way to prototype the application at low cost.

But if you are really going heavyweight, you may need to change any or all of that in the future.

If you look at the context of a very large user base and process table, then obviously multithreading will win over solely replicating code pages everywhere. That's at lest most database engines will do, and Zeus rather than apache used to be the web serer of choice for high usage as well..

But there are many man more issue at stake. Mysql is good but even it is a bit flimsy when it comes to atomic transactions and rollback. Ther are also less safeguards in it, in that the way tables are related in the relatinal database is not inherent in the engine.

That is, consider an applicationn like a sales order, where one table reprsentst the order header and a series of rows in another table represent the actual items that comprise the order. In MySQL there is as far as I know no way to express that relationship other than coding in the forms themselves. Whereas I believe that Oracle allows you to assign that relationship so that attempting to e.g delete a header without also deleting the lines associated with it, gives an error.

With respect, I think you are approaching this the wrong way around. First you have to define the application in a reasonable amount of detail. That should suggest the softare plastforms that will be best for it, and then and only then, should you worry about what hardware it should run on.

E.g. If you were t pick Oracle, you simply ask them 'what is the platform you are most happy to support' and if it happens to be a Cluster of SUN's linked by optical fibres, thats what you buy.

Millions of transactions a minute is stiff going irrespective of anything else.

I would be worried about Disk I/O at least as being far more relevant than what database package.. Received on Mon Feb 16 2009 - 01:31:41 CST

Original text of this message