List:General Discussion« Previous MessageNext Message »
From:Chris Nolan Date:February 10 2004 3:25pm
Subject:Re: SQL2000 and MySql
View as plain text  
Hello Martijn!

It seems that whenever we both comment in a thread, you enlighten me 
greatly!

Martijn Tonies wrote:

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

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

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

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

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

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


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

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

>  
>
>>6. MySQL's commercial licence is quite nice for businesses as there are
>>written assurances regarding the software's capabilities.
>>    
>>
>
>no comment.
>  
>
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."

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

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

>  
>
>>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.
>  
>
Nor can MS a lot of the time - it gets them into trouble. :-)

>  
>
>>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
>  
>
For anyone reading this message, allow me to sumarise the document that 
Martijn has pointed out above.

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

>  
>
>>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? ;-)
>  
>
I could only name a few reasons for migrating away:

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

>  
>
>>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*
>  
>
Beer? I would rather deploy SCO UnixWare than drink beer! How about vodka?

>With regards,
>
>Martijn Tonies
>Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
>Server.
>Upscene Productions
>http://www.upscene.com
>
>
>  
>
Regards,

Chris

Thread
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