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...
Matthias - 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.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
