Re: Which SQL is the best for servers?

On Feb 16, 6:09 am, pg <pen..._at_catholic.org> 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.

Perhaps you should clarify here - what exactly do you mean by millions of "database enquiries per minutes"?

Will these be reads? Or will there be lots of updating going on?

What is the nature of these database "enquiries"?

> 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.

Fine - Oracle won't be supported on *BSD.

> I know that Oracle, MySQL and PostgreSQL are all designed for heavy
> duty uses.

Yes - but what sort of heavy duty use? MySQL will be better IMHO for reading - less transactional overhead - which is both good and bad!

> 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?

All of the commercial vendors specifically forbid benchmarks - except the
ones they choose to publish themselves!

> 2. Since the server may come with only 32GB of RAM, which SQL can run
> the "leanest" - that is, not a memory hog?

32GB of RAM is a large system - but RAM isn't everything! What is the OS going to be? That's your first decision.

What about the disk configuration? What's the CPU configuration?

> 3. The server might also become a web-server, which SQL can tie itself
> to the Web-based enquiry they best?

Generally a web server feeds user input to an app server which then fires SQL at a database.

These tiers should all run on separate machines - or at least separate virtual machines.

> Please give me your suggestion / opinion. Thank you !!

You could look at Firebird - it's solid and simple to administer. The answer to this
question depends on your requirements, which you haven't explained enough here.

Paul... Received on Mon Feb 16 2009 - 10:57:14 CST