Re: Which SQL is the best for servers?

From: Michael Austin <maustin_at_firstdbasource.com>
Date: Mon, 16 Feb 2009 18:54:52 -0600
Message-ID: <AVnml.22948$ZP4.17838_at_nlpi067.nbdc.sbc.com>



Serge Rielau wrote:
> Matthias Hoys wrote:
>>> 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...).
>>
>> I really wouldn't go for database independence ... Choose a RDBMS and 
>> use all of its features ! 

> Nothing like a serious addiction combined with a single source to get
> your fix to loose a lot of money...
>
>

This is addressed to the OP: - you should take note of that statement from Serge... and myself. While bigoted in our db of choice, we do agree that single-sourcing your options is a GREAT way to send your favorite salesman to Tahiti while you play with the box the toys came in...

I work for one of the top 50 Oracle support customers (we also have DB2, MySQL and SQL Server). I use MySQL on my home servers. Each has their strengths and weaknesses, each has their place in the overall scheme.

Again, define your transactional data flow as best you can (and if you need help there are lots of really good consultants out here that can help if you need it), from there you would figure out Database engine, OS platform, storage options and so on down the line. With the transactional load you started out with - it is HIGHLY unlikely that it will be Linux on a small server.

[since I am posting this from the c.d.o.s NG] RAC is highly scalable. I have recently had to add a node to a DW that adds more data in a day than most db's do in 2-3 years... And we did this on the fly. We have other RAC environments that are "commodity" servers - this one is not. RAC was chosen in this case for its scalability as well as availability.

Working for my current employer, I have a real good idea as to what millions of transactions actually look like and what it takes to support that kind of workload. Received on Mon Feb 16 2009 - 18:54:52 CST

Original text of this message