It seems that whenever we both comment in a thread, you enlighten me greatly!
Martijn Tonies wrote:
Hi Chris,The TCO paper on the MySQL site would be one of my primary points of reference. There are several points that would be hard to argue against though:
I understand that you like MySQL but ...
Hmm....for practical purposes:things.
1. MySQL is going to cost you a lot less, no matter which way you do
This is a pretty bold statement. Can you back this argument with some references regarding TCO and development time for a particular project? Obviously, there's more than just licensing costs.
* MS SQL Server has 3 licencing models - per processor, per user or per device. Either you can pay lots now and only pay a lot more if you decide you need more CPUs or take a gamble / educated guest about how many things you need to plug into it. Not having to worry about these factors is nice and the argument that you are able to use the software irrespective of upgrades, increased user numbers or more connecting devices is also very supporting of the above statement.
* History has shown that applying patches to MS SQL Server is a process ranging from quite pleasant to quite painful (remember the initial Slammer patchset?). MySQL's upgrades are quite seamless by comparison, and I dare say are trivial to rollback. Downtime is one of the most often ignored factors in ROI and TCO studies.
* MySQL training and certification is available and my research shows that MySQL AB are very reasonable with the charges associated with that service.
* Assuming that my points below regarding performance are correct (I'm sure that Heikki will stand by InnoDB and back up anyone preaching it's performance benefits), the lower hardware costs are an important factor (as in lower for a given performance target).
* Clustering packages are available for MySQL currently, but I can't figure out where on earth to look for them. I can say that MySQL AB are going to be demonstrating their clustering solution at the upcoming expo - let's hope it's under the same licence as all these other nice toys that come out of MySQL AB.
Things are getting better, but I often make an argument for having a higher entry barrier for technical people due to the large number of Windows "experts" who don't even know who Dave Cutler is. Either way, it's all good!As a personal note: at a company we started a few years ago, we actively select Linux as the server OS and Firebird as our primary database simply because of the licensing costs we couldn't afford then, but we did have the spare time for learning the more advanced Linux stuff (to our minds, that is) and the somewhat less catered for UI in Linux. Mind you: things are getting better in the Linux world :-)
Indeed! The fact that you need to marry the child of someone high up at any of the big three before you can publish benchmarks of their products without getting into a lot of trouble doesn't help matters at all! I'm hoping that the new benchmarks page at MySQL's site will be up soon though, saving me from thinking too hard on this point.2. MySQL is going to perform better for the vast majority of workloads.
The only place where MS SQL Server *might* have an advantage is in
situations where it's additional language features are able to do things
that you would need to do in your application should you use MySQL (and
comparisons in this area in the past by many people have still shown
MySQL to have a speed edge).
Despite comparisons: still a pretty bold statement. There are plenty of comparisons out there that don't say anything at all. Heck, the whole "we can do this many transactions per second if we use 64 CPUs, this many drives etc etc on a clustering system" is total hogwash, both you and me know that. It's just the sales people who are out of luck there ;-)
I think that your (one of) statement is not needed - InterBase seems to have been the first, with Oracle coming along later and thinking "This thing is so funky! Quick, we must build one!". At the moment though, I can only name the following 5 multiversioned engines:3. MySQL's "primary" (BDB fans, please don't flame me) transactional
table type is the fastest transactional storage engine on the planet,
has an option for proper binary backups and has very quick and automatic
recovery, regardless of how ugly a crash is. MS SQL's "old-style"
non-multiversioned system can be problematic in this regard in some rare
cases.
Multi-versioning - in my eyes - is the future when it comes to databases with regard to concurrency (MS SQL has row locks!). Nice to read that more and more database engines are using this MV instead of locks. Obviously, InterBase was (one of?) the first about 20 yrs ago. And yes, it certainly can help when stuff crashes. And it makes development easier as well. In short: good argument.
MySQL/InnoDB, PostgreSQL, Oracle, Firebird, Interbase
Do you have any others to add? Yukon definitely won't be and I doubt IBM would dare do anything drastic to the DB2 code base. We know that Foxpro, Access and Filemaker Pro aren't.....
For all those interested, here's a list of commerical databases that still use page-level locks in some way, shape or form:
MS SQL Server, Gupta SQLBase (coming to Linux soonish), InterBase, FireBird, Sybase
This isn't much of an argument as such, just showing that neither product has an advantage here. I have seen firsthand instances of an ALTER TABLE table ADD INDEX ... statement on MS SQL Server screwing up a number of optimiser statistics and resulting in query execution times changing noticably for an interval of time.4. ALTER TABLE statements in both products (currently at least) will
result in a SHARED LOCK being placed on the table in question. Yukon
(SQL Server 2003) will remove this limitation though.
no comment.
I always like answers on this list! For instance, on this list the creators and high-profile users (such as yourself) happily interact and respond to soon-to-be BEng (SE) peoples like myself.
5. MySQL has one of the most active communities of any database product.
Getting help isn't a problem on this mailing list - it's more a question
of getting people to stop giving you help.
MS SQL has an active community as well. Whenever I needed
to know something, I got my answers, although I didn't always
like them :-)
Admittedly, I haven't read through the licence, but the assurances you get on the licence document are a lot more comforting than the "If SQL Server 2000 shaves your cat, it's not our problem. If SQL Server 2000 shaves your neighbour's cat due to you installing a device with terrible drivers, you'll pay our court costs when we get sued."
6. MySQL's commercial licence is quite nice for businesses as there are
written assurances regarding the software's capabilities.
no comment.
They are indeed much better, but the fact that Windows is a product and UNIX is a paradigm, platform, industry group-around and senior citizen in the CS world speaks volumes for it. Besides, the only x86 UNIX-ish OSes that are accessible to the public and can't be obtained without charge for any purpose are both of questionable quality, lineage and survivability...
7. BIG ARGUMENT: MySQL is multi-platform and quite platform agnostic.
Migrating between architectures and/or operating systems is a non-issue.
With SQL Server, you're stuck with either of the pathetic excuses for
server OSes, Windows 2000 Server or Windows 2003 Server.
Win2K and 2K3 have become much better than the previous NT4.
Nevertheless, being able to use a database engine on your favourite
OS of choice, is, in my eyes, a pro-argument.
I should have really mentioned that MS SQL Server comes with a hot backup tool, an added extra for MySQL. That said, there are alternatives to MS's tool that make backups a lot more managable and scriptable.
8. MS SQL's additional tools may be of interest to you (see MS's product
page, particularly their product comparison page for the number of nice
things included with SQL Server). The vast majority of this stuff exists
for MySQL as well though, you will have to get your hands on it
seperately though.
no comment.
Nor can MS a lot of the time - it gets them into trouble. :-)
9. The general opinion in industry is that MS SQL Server's replication
capabilities are not ready for prime-time. MySQL's replication
capabilities are very solid.
I cannot comment on the state of the MS SQL replication stuff.
For anyone reading this message, allow me to sumarise the document that Martijn has pointed out above.
10. With MySQL, it's easy to get support for it from the people who
actually wrote it. If there's a feature that you desperately need and
you're willing to pay for it (and paying for it equates to about the
same as buying a decent MS SQL Server setup), they may very well be able
to help you out!
Obviously true. Except for the license price of MS SQL - there's
always the "how to get a discount" guide :-D
Have a 3 hour conversation with an MS Sales rep at your office and mention all of the following terms:
* Oracle * DB2 * Linux * Redhat * NT 4 retirement * MySQL * J2EE
I could only name a few reasons for migrating away:
11. If you change your mind later, migrating from MySQL to another
database engine is a well-travelled path with utilities and full-blown
product offers all over the place.
Hmm. In your eyes, why would someone do that? ;-)
* Management all get labotomies over the weekend and decide to migrate to MS SQL Server. :-)
* You're a total cheapskate and refuse to pay for a commercial licence and want to develop an app that links to libmysqlclient but will not be under the GPL.
* You want to execute statements such as this: ALTER TABLE table ADD INDEX sum ((col1 + col2 + col3));
* You want to be able to ROLLBACK DML statements
* You're bored on a Saturday night and want to prove to your friend that Foxpro is a sick joke that nobody "got" when it was released.
Of course, there are some catches when it comes to MySQL.Additionally, MySQL AB didn't add DB-style functions to Excel. This is a major point of grief for me, as I am going to set one of those disgusting internet "icons" as background for the next person that rings up with a query relating to the "Excel Database".
12. MySQL AB weren't responsible for afflicting the world with the Jet
database engine (Access) or Visual FoxPro, thus they are more
trustworthy than MS! :-)
*g*
Beer? I would rather deploy SCO UnixWare than drink beer! How about vodka?
13. You'll have my eternal gratitude if you use MySQL over MS SQL
Server...I'll send you a postcard.
Send beer instead... *g*
With regards,Regards,
Martijn Tonies Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL Server. Upscene Productions http://www.upscene.com
Chris
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
