I'd like to thank everyone for giving such helpful and detailed responses; 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 more than 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 know 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 bigger. 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 alone is enough of a business reason not to use it, all other things being equal. It's determining the extent to which other things _are_ equal that this is about-- if Oracle has a lot of features that we don't need, it doesn't matter that it has them. > 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 anything 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 application language (and as someone pointed out, foreign keys are available right now 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 my reasons. If I can convince them that productivity, cost, and support will be 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. Elizabeth --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
