Comment Re:For all the PostgreSQL zealots out there... (Score 1) 273
It sounds from the length of the brutal attack on Postgres that people in glass houses shouldn't throw stones. Pissing on your own doorstep eh? You complain about 'zealots' yet you yourself sound like you should join Ossama and his mates and go blow up the Postgres head developer!
As a professional consultant who has deploy lots and lots and lots of enterprise, small and medium stuff (think FT.com, O2, Vodafone, Schroders, etc etc) and having ran a consultancy the key factors in choosing a database are
1) Support - how many people know it and if it breaks can it be fixed in a cost effective and fast manner?
2) Reliability - does it go down and can we mitigate the risks with clustering?
3) DR - can a backup be easily restored?
4) Cost of both dev and licenses.
5) Does it meet our architectural needs? For example at one of my major clients we had a realtime billing system for SMS's. It had a high volume of data flowing from table to table. The original system had no stored procedures and took ages - like 35 hours for a days data. We re-wrote in stored procs and it flew - 600% speed increase. Could we do this with MySQL? NO!!!!!!
I don't choose db's for my customers just because I'm a zealot. Some implementations use Oracle, some Postgres, some MySQL, some Sybase ASE.
If the people on Slashdot who scream and shout utter rubbish actually thought of requirements I wouldn't keep turning up to customers who had inadequate, poorly maintained systems designed by schoolkids.
Get a grip. Think of the factors, risks and choose the implementation on that. Don't dive in thinking 'I only know mysql and everything else must suck' - do some research, draw up plans, ask friends and get in some consultants.
As a professional consultant who has deploy lots and lots and lots of enterprise, small and medium stuff (think FT.com, O2, Vodafone, Schroders, etc etc) and having ran a consultancy the key factors in choosing a database are
1) Support - how many people know it and if it breaks can it be fixed in a cost effective and fast manner?
2) Reliability - does it go down and can we mitigate the risks with clustering?
3) DR - can a backup be easily restored?
4) Cost of both dev and licenses.
5) Does it meet our architectural needs? For example at one of my major clients we had a realtime billing system for SMS's. It had a high volume of data flowing from table to table. The original system had no stored procedures and took ages - like 35 hours for a days data. We re-wrote in stored procs and it flew - 600% speed increase. Could we do this with MySQL? NO!!!!!!
I don't choose db's for my customers just because I'm a zealot. Some implementations use Oracle, some Postgres, some MySQL, some Sybase ASE.
If the people on Slashdot who scream and shout utter rubbish actually thought of requirements I wouldn't keep turning up to customers who had inadequate, poorly maintained systems designed by schoolkids.
Get a grip. Think of the factors, risks and choose the implementation on that. Don't dive in thinking 'I only know mysql and everything else must suck' - do some research, draw up plans, ask friends and get in some consultants.
