MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Martijn Tonies Date:February 10 2004 2:39pm
Subject:Re: SQL2000 and MySql
View as plain text  
Hi Chris,

I understand that you like MySQL but ...

> Hmm....for practical purposes:
> 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.

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 :-)

> 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 ;-)

> 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.

> 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.

> 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 :-)

> 6. MySQL's commercial licence is quite nice for businesses as there are
> written assurances regarding the software's capabilities.

no comment.

> 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.

> 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.

> 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.

> 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

> 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? ;-)

Of course, there are some catches when it comes to MySQL.

> 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! :-)


> 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,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Upscene Productions

SQL2000 and MySqlAubais309 Feb
  • Re: SQL2000 and MySqlMartijn Tonies9 Feb
Re: SQL2000 and MySqlPeter J Milanese9 Feb
Re: SQL2000 and MySqlMartijn Tonies9 Feb
  • Re: SQL2000 and MySqlChris Nolan10 Feb
    • Re: SQL2000 and MySqlEd Leafe11 Feb
      • Re: SQL2000 and MySqlChris Nolan12 Feb
        • Re: SQL2000 and MySqlEd Leafe12 Feb
          • Re: SQL2000 and MySqlChris Nolan12 Feb
            • Re: SQL2000 and MySqlEd Leafe12 Feb
Re: SQL2000 and MySqlMartijn Tonies10 Feb
  • Re: SQL2000 and MySqlChris Nolan10 Feb
Re: SQL2000 and MySqlMartijn Tonies10 Feb
  • Re: SQL2000 and MySqlPeter Zaitsev10 Feb
  • Re: SQL2000 and MySqlChris Nolan11 Feb
    • Re: SQL2000 and MySqlJochem van Dieten11 Feb
      • Re: SQL2000 and MySqlChris Nolan11 Feb
Re: SQL2000 and MySqlMartijn Tonies11 Feb
Re: SQL2000 and MySqlMartijn Tonies11 Feb