I'd like to thank everyone for giving such helpful and detailed
it's the sort of thing that shows me how good the support here can be!
I did want to address some things that may not have been clear enough
in my original message. When I said "not speed" I didn't mean that speed
wasn't important at all. It's that I'm pretty confident that MySQL is
fast enough for what we need, and when I see MySQL vs. Oracle questions
here they always tend to be about benchmarking, about convincing
people that MySQL is fast enough. I don't think that's the case, and I
that we'll never be in a situation where we need something monstrously
huge (ten thousand simultaneous users doing complex queries on tables
with millions of rows) that might genuinely require something much
I'll respond to John's points but most of the things he asks have already
been pointed out by other people.
On Friday, August 16, 2002, at 08:25 AM, John Griffin wrote:
> Hi Elizabeth,
> The first question I would ask why don't you want Oracle? If you can't
> come up with a good business reason why your company shouldn't go with
> Oracle I would say you have already lost the battle.
As others have pointed out, Oracle is much more expensive, and that
enough of a business reason not to use it, all other things being equal.
determining the extent to which other things _are_ equal that this is
if Oracle has a lot of features that we don't need, it doesn't matter
that it has
> The second question is who is making the purchasing decision? If it's
> middle management or the bean counters then you have pretty well lost
> again because nobody ever lost their job for buying Oracle.
This is perhaps the biggest problem--they could just not listen to
and go with the safe decision.
> MySQL also has what some people consider fairly serious drawbacks.
> MySQL does not support triggers or foreign key constraints (yet) so
> data integrity is always at risk. There is no equivalent of PL/SQL in
> MySQL, all database procedures etc. must be written in a 3GL, such as
> C, and then linked in.
Since we'd be doing everything from scratch, many of these don't really
apply, as there are usually workarounds that can be written in the
language (and as someone pointed out, foreign keys are available right
in InnoDB anyway). And the more we rely on things like PL/SQL the more
difficult it is to ever migrate.
> If you feel your shop should become a MySQL shop I suggest you look at
> the business reasons why and use those reasons to argue your case for
> you. Technical coolness or altruistic support of the open source
> movement doesn't cut it with most managers. Productivity, cost, and
> support usually does.
I appreciate that, and I do hope that I can get management to listen to
reasons. If I can convince them that productivity, cost, and support
just fine with MySQL, it would be nice to have the technical coolness and
altruistic support of the OS movement as icing on the cake!
Thanks again to everyone who took the time to reply. I certainly didn't
meant to start a MySQL vs. MS-SQL battle either.