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 *g* > 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... >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 anyones 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 Server. Upscene Productions http://www.upscene.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
