List:General Discussion« Previous MessageNext Message »
From:Chris Nolan Date:February 11 2004 2:54am
Subject:Re: SQL2000 and MySql
View as plain text  
Martijn Tonies wrote:

>Hi Chris,
>
>  
>
>>It seems that whenever we both comment in a thread, you enlighten me
>>greatly!
>>    
>>
>
>;-) ... I'm learning more about MySQL with every post. Ok, maybe
>not every post, but still ... *g*
>
>I tend to be a critic sometimes, but I'm a really nice guy. Believe me on
>this one ;-)
>  
>
You have to have critics, otherwise myths get propogated everywhere!!

>  
>
>>>>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.
>>    
>>
>
>Ah, good. Mentioning this the first time in your statement would have
>pointed people to the right document in the first place.
>  
>
Yes, but that would have required some actual thought on my part. :-)

>  
>
>>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).
>>    
>>
>
>Note: when using InnoDB in 24x7 environments, you need to purchase an
>additional hot-backup tool to do your backups. Not expensive at all though.
>
>  
>
Not expensive doesn't do justice to the excellent value proposition that 
InnoDB Hot Backup is.

>>* 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!
>>    
>>
>
>As someone who uses Windows all day long and likes to argue with
>Unix/Linux techies: I really like the "clickety-click" stuff. But I do agree
>with your remark about the so-called "experts".
>
>  
>
The rate that KDE and GNOME are advancing at reminds me of the landscape 
a few years ago, when usability experts said that Windows and MacOS were 
starting to reach parity in terms of usability. Hopefully the open 
source world won't just settle for parity (they're way ahead in many 
ways in my opinion).

>>>>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
>>    
>>
>
>*g*
>  
>
Additionally, it is an accepted fact that MySQL is faster than the 
mighty, mighty PostgreSQL. It is an accepted fact that PostgreSQL 
developers don't lie. The PostgreSQL developers say that they are faster 
than most commercial databases in their normal fsync mode. Therefore, by 
communicativity of implication, MySQL is faster than most (if not all) 
commercial databases.

>  
>
>>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?
>>    
>>
>
>ThinkSQL ( www.thinksql.co.uk ) and I believe MimerSQL as well
>( www.mimer.com ) but I'm not sure. Then there are a lot of smaller
>db engines that use the same technique. And of course the storage
>engine inside www.netfrastructure.com - also created by the original
>creator of InterBase. But it's more refined and faster - obviously, the
>effect of modern hardware and less worries about memory etc...
>  
>
Mimer seems to have a fair bit in common with MS SQL Server. For 
instance, one of their big features is Optimistic Conflict Control. They 
do claim "non-locking transaction control" though.

>  
>
>>Yukon definitely won't be
>>    
>>
>
>I do believe Yukon get's a snapshot transaction isolation - any word
>on how they are going to implement this?
>
>  
>
In an amazingly dodgy manner? Given the amount of time they've been 
working on it, I'd say we're either going to see something entirely new 
(mutliversioning perhaps) or something "bolted on" to the old model 
that's just taking forever to implement and debug.

>>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
>>    
>>
>
>As far as I know, InterBase and Firebird don't use page-locking. Ever.
>Any references on that?
>  
>
I can't put my hands on it at the moment, but I have seen something in 
the developer docs regarding the data structures used to represent locks.

>  
>
>>>>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."
>>    
>>
>
>Don't forget the "you can use this software whereever you like except in
>true critical areas" clauses...
>  
>
And the "You will not do compatibility testing! Documents relating to 
this are available! Make do with those!!!" clause.

>  
>
>>>>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.
>>    
>>
>
>I bet one of the reasons why there are sooooo many MSSQL tools is
>that "where there's MSSQL, there's money". No offence, but from what
>I see sometimes in open source worlds (I had this with Firebird too) is that
>I - as a tool vendor - get questions like "you create a tool for an open
>source product and you're asking MONEY for it? tss tss"... Well, bread,
>table and so on :-)
>  
>
Which miserable sod would question your right to charge cash for your 
tools? Nothing is stopping them from creating a free alternative and 
your contribution to the free software world in other ways is quite 
notable. The fact that you even support the big open source databases is 
an excellent push for funky software that comes with source code!!

>  
>
>>>>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. :-)
>>    
>>
>
>I once heard about someone who was programming the Oracle engine
>and his exact comments about the state of the code with regard to a
>transaction rollback was: "hairy". Still, it works though :-)
>  
>
Along those lines, I have a friend that says to me "I wouldn't store my 
MP3 list in Oracle! Give me Sybase, MySQL or FoxPro any day!". After 
mentioning FoxPro, I laughed at him.

> >>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
>>    
>>
>
>woohoo, darn, there goes the secret *g* ... It does work though. With
>pretty much any company out there.
>  
>
Also you could mention Novell and Sybase. I think Microsoft still have a 
major grudge against the network dudes from Utah.

>  
>
>>>>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.
>>    
>>
>
>I can think of a few others:
>
>- stored procedures (not finished with MySQL)
>- triggers (not even on the roadmap with MySQL?)
>- check constraints (please, Heiki?!)
>
>I'm a constraint-freak, if you like. I want my database to check the
>data. In all sorts of possible ways...
>  
>
Triggers are slated for the 5.1 timeframe, along with FK constraints for 
all table types (including BDB?).
Check constraints have beem discussed in various presentations (at the 
2003 MySQL conference, they were mentioned specifically with regard to 
MySQL's compliance to SQL92 and SQL:1999).
The stored procedure support in MySQL looks like it will come along to a 
very complete fruition - with the ability to plug in modules that can 
execute PL/SQL and T-SQL. Once we get some form of T-SQL support (from 
some community project I would like to be a part of ), I will definitely 
work on writing a proxy program that allows you to use MySQL instead of 
MS SQL Server, just to annoy his Billness.

>  
>
>>>>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?
>>    
>>
>
>Naah, no vodka for me ;-)
>
>Either way, one thing I should say, is that there is a database engine for
>anyones
>purpose, depending on your need. Sometimes, this can be MySQL, sometimes
>it needs to be something else...
>  
>
There is indeed, but at no point should that database engine ever be FoxPro.

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