> It seems that whenever we both comment in a thread, you enlighten me
;-) ... 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
> >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
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
> * 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
> * 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
> >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 ( 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...
>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...
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL