MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Martijn Tonies Date:February 10 2004 4:38pm
Subject:Re: SQL2000 and MySql
View as plain text  
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 ;-)

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

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

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

> >>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
> >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 ( ) and I believe MimerSQL as well
( ) 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 - 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...

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

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

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

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

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

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

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

> >>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
purpose, depending on your need. Sometimes, this can be MySQL, sometimes
it needs to be something else...

Take care.

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