Re: Which SQL is the best for servers?

Paulie wrote:
>
> On Feb 16, 6:09 am, pg <pen(dot)(dot)(dot)(at)catholic(dot)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.

Huh... 32GB of RAM is NOT a large system - more of a smallish-medium
size. :)

<snip>

First: You really do need to define your database and transaction model
before figuring out what engine to use.

Your enemy is going to be scalability in the I/O bus unless everyone is
querying the same information constantly. Oracle's cache or MySQL Query
Cache could handle a lot of that - Most db engines have some sort of
caching feature you *may* want to use.

Should you choose an open-source, make sure your code AND your DDL uses
as much ANSI standards as possible so when you do need to move to
something else, it won't be as painful. (auto-incrementing columns vs.
sequences etc...).