Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

8 Reasons Not To Use MySQL (And 5 To Adopt It)

Zonk posted more than 7 years ago | from the for-every-product-turn-turn-turn dept.

Databases 288

Esther Schindler writes "Database decisions are never easy, even — or maybe especially — when one choice is extremely popular. To highlight the advantages and disadvantages of the open-source MySQL DBMS, CIO.com asked two open-source experts to enumerate the reasons to choose MySQL and to pick something else. Tina Gasperson takes the 5 reasons to use MySQL side, and Brent Toderash discusses 8 reasons not to. Note that this isn't an 'open source vs proprietary databases' comparison; it's about MySQL's suitability in enterprise situations."

cancel ×

288 comments

Sorry! There are no comments related to the filter you selected.

oooo, goody (0)

Anonymous Coward | more than 7 years ago | (#19275625)

A nice flame war. I'm just going to sit back, crack a beer and enjoy it. It is almost memorial day weekend, you know. Hopefully it get hot enough in here to roast a hot dog.

Re:oooo, goody (0)

Anonymous Coward | more than 7 years ago | (#19275697)

Roast a hot dog? That's a really modest statement.

Re:oooo, goody (0, Offtopic)

Mattintosh (758112) | more than 7 years ago | (#19275729)

There's nothing better than a nice wiener-warmer.

Perhaps I shouldn't talk about warming wieners in the same post as "flaming on"... Ah, what the hell...

Flame on!

Re:oooo, goody (4, Informative)

tomhudson (43916) | more than 7 years ago | (#19275709)

The guy is arguing with himself - the first 2 reasons:
  • MySQL Uses the GPL
  • MySQL Doesn't Use the GPL

Oh, boo-hoo, dual-license bad!

The rest of the article is equally stupid. For example, "If you already own proprietary licenses ..." has NOTHING to do with whether Mysql is a good fit or not. Next it will be "I hae Pepsi in the fridge; I really want a glass of free cold water or a bottle of Coke right now, but I'll buy some more Pepsi instead seeing as I've already standardized on it".

Re:oooo, goody (3, Insightful)

Ucklak (755284) | more than 7 years ago | (#19276233)

The 5 reasons to use it are far more informative than the 8 stupid reasons not to use it.

It boils down to corporate culture.

Re:oooo, goody (1)

moderatorrater (1095745) | more than 7 years ago | (#19276423)

Of all the reasons to not use MySQL, and there are a lot, the licensing is probably the least likely to convince someone to use or not to use it. And the author presented those reasons in a stupid way, giving ridiculously stupid ways the licensing could effect you.

Re:oooo, goody (1)

SP33doh (930735) | more than 7 years ago | (#19276779)

to be fair, water, coke, and pepsi all use basically the same syntax ;]

Re:oooo, goody (5, Funny)

DysenteryInTheRanks (902824) | more than 7 years ago | (#19275875)

A nice flame war. I'm just going to sit back, crack a beer and enjoy it. It is almost memorial day weekend, you know. Hopefully it get hot enough in here to roast a hot dog.

Oh goody! I'll help get things going:

  • MySQL users will have to wait until you are done with the fire before they can roast their hot dogs, since MySQL is not a real database and does not support concurrent roasting;
  • I've read the PostgreSQL manual eight times and still can't figure out something as bloody simple as roasting a hot dog, though I did figure out I have to call VACUUM before I can apply ketchup;
  • Serious enterprises who care about their hot dogs use Oracle, since you can roast over 10,000 dogs at once and optionally impart the taste of filet mignon;
  • If you try to roast a footlong hotdog using MySQL it will silently truncate it to regular size, causing your child to cry;
  • Oracle will sue you if you complain about the difficulty of starting your fire or the blackened taste of the dogs;
  • With SQLite your hot dogs are pre-roasted;
  • Last year on Memorial Day, mysqld leapt out of my MacBook Pro and pushed my cousin into the fire, resulting in third degree burns. And also it causes cancer. And terrorism. Blindness. Violent puppy death. BOO! MYSQL IS SCARY DON'T USE MYSQL!!


Happy Memorial Day!

Re:oooo, goody (1)

iknownuttin (1099999) | more than 7 years ago | (#19275933)

Your post is timestamped after 5 PM, so I won't make a crack about hitting the beer early. ;-)

Happy weekend to you, too!

Re:oooo, goody (4, Funny)

Doctor Memory (6336) | more than 7 years ago | (#19276053)

Serious enterprises who care about their hot dogs use Oracle, since you can roast over 10,000 dogs at once and optionally impart the taste of filet mignon;
Yeah, but only if your locale is set to US-ASCII. If you try to use UTF-8, taste defaults to pate de fois gras. However, under US-ASCII "SELECT beer FROM fridge" will return only 'Budweiser' or 'Miller Lite'...

Re:oooo, goody (1)

DysenteryInTheRanks (902824) | more than 7 years ago | (#19276405)

Heh, I think Larry Ellison also added a special JIS encoding mode which gives you kind of an unagi flavor ;->

Re:oooo, goody (1)

sm4096 (1104499) | more than 7 years ago | (#19277381)

I initially came across this article when no one had posted anything. It's a good thing I didn't waste my time reading it and just came back for the good stuff. The article is probably boring but I agree that the the flame war could should at least be interesting.

Warning: mysql_connect(): Too many connections ? (0)

lectos (409804) | more than 7 years ago | (#19275663)

Warning: mysql_connect(): Too many connections ?

Re:Warning: mysql_connect(): Too many connections (4, Informative)

nuzak (959558) | more than 7 years ago | (#19275867)

No, that's part of the "8,573 reasons to not use PHP" article.

Re:Warning: mysql_connect(): Too many connections (4, Insightful)

DarkSkiesAhead (562955) | more than 7 years ago | (#19275903)

Warning: mysql_connect(): Too many connections ?
That warning should really read: "Warning: crappy sysadmin" No reason to see it on a well-run site.

First reason not to... (0, Flamebait)

mobby_6kl (668092) | more than 7 years ago | (#19275667)

1) It's not a real database

Uh, oh. The pro mysql guy can't count. (0)

Anonymous Coward | more than 7 years ago | (#19275695)

He lists six reasons. On the other hand, the anti-mysql guy tries to up his reason count by breaking licensing issues into two reasons

Re:Uh, oh. The pro mysql guy can't count. (5, Funny)

Mattintosh (758112) | more than 7 years ago | (#19275771)

The pro-MySQL "guy" can't pee standing up, either. "He" is a she.

The anti-MySQL guy is Canadian, though, so he probably doesn't pee standing up either. Lots of beer -> floor -> bladder evacuation. I kid, I kid...

Re:Uh, oh. The pro mysql guy can't count. (4, Funny)

drinkypoo (153816) | more than 7 years ago | (#19276307)

The pro-MySQL "guy" can't pee standing up, either. "He" is a she.

Just keepin' it real. Gotta love the internet.

Ready...Set... (4, Funny)

mugnyte (203225) | more than 7 years ago | (#19275727)

...Fanboi RDBMS wanker post race begins.....

  NOW

  Seriously, the articles do nothing more than point out the *best places* MySQL may or may not work, not that it is better than anything.
  One size yet again does not fit all.

    Hmmm..where's my Model204 [cca-int.com] manuals...?

What about condoms? (0)

Anonymous Coward | more than 7 years ago | (#19275831)

One Size fits all!
Seriously.
I know there are different sizes. But is there really a point? They do stretch quite well

http://www.metacafe.com/watch/335285/how_strong_is _a_condom/ [metacafe.com]

Re:Ready...Set... (4, Insightful)

jrockway (229604) | more than 7 years ago | (#19276435)

These two articles were some of the worst pieces of literature I've ever seen in my life. The GPL and BSD licenses are "too free"? "Ajax" is a programming language powered by MySQL? Etc., etc. Oh my God... what crap!

Ah, yes. Enterprise. (0, Flamebait)

Anonymous Coward | more than 7 years ago | (#19275737)

I know all about enterprise solutions. Those guys over at dailyWTF?! [worsethanfailure.com] can't shut up about them. Every developer should model himself after what Enterprise Pushers say, because they obviously know best. XML, COM+ and J2EE for teh people!

The 8 reasons not to use mysql (5, Informative)

mgkimsal2 (200677) | more than 7 years ago | (#19275747)

1. MySQL Uses the GPL
2. MySQL Doesn't Use the GPL
3. Integration With an Existing Environment
4. Product Maturity
5. Feature Set Maturity
6. Availability of Certification
7. Corporate Considerations
8. Perception of Scalability

They all have *some* merit, but all are very dependent on your situation. 1 and 2 seem to cancel each other out, as in if #1 is an issue for you, #2 probably wouldn't be. #3 is sort of weak, arguing that if you already have many other databases, adding yet another different system is detrimental. That's not an argument against MySQL, but against disparate systems altogether. The rest of the issues are matters of degree. "While MySQL does have a certification training program, its training availability is not nearly as widespread as for, say, Oracle or MS-SQL Server." True, but if you're comfortable with the level of quality of certified MySQL people, then go forward. It'll contribute to the general upward spiral of adoption, hiring, certification and so on. MySQL is going to keep growing, it's just a matter of how quickly and in what directions.

P.S. Printable version here -> http://www.cio.com/article/print/113111 [cio.com]

Re:The 8 reasons not to use mysql (4, Informative)

EsbenMoseHansen (731150) | more than 7 years ago | (#19275905)

Are those supposed to e reasons? How about

  • Command line completion in mysql client sucks
  • Transactional support is a bit sub-par compared to postgres.
  • Unless carefully configured, not nulls, group bys and quoting are broken.
  • Sequence support is also a bit sub-par.
  • Some entity name's case sensitivity is dependent on host filesystem
  • Subselect support slow and memory hungry (I've only tested this a little)
  • Blobs cannot be accessed as streams

Only 7, but all of those are real real complaints :)

That's not the target audience (3, Insightful)

Doug-W (165055) | more than 7 years ago | (#19276145)

The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.

Re:That's not the target audience (4, Insightful)

EsbenMoseHansen (731150) | more than 7 years ago | (#19276491)

The article is in CIO magazine, none of the downsides you mention is of a concern for a CIO. A Product manager? Maybe, even then probably not.

If you are in any position where you are choosing between databases, you have three cases:

  1. You understand these issues
  2. You have delegated the decision to someone who does
  3. You are incompetent
  4. You are toying around

Sorry about the M.P. reference there :o)

Re:The 8 reasons not to use mysql (4, Informative)

larry bagina (561269) | more than 7 years ago | (#19276325)

#8: "February 31, 2007"

Re:The 8 reasons not to use mysql (2, Informative)

EsbenMoseHansen (731150) | more than 7 years ago | (#19276457)

#8: "February 31, 2007"

I almost included that one, but they have actually fixed that 5.02. You can still specify ALLOW_INVALID_DATES as an sqlmode for that nostalgic feeling, though.

Re:The 8 reasons not to use mysql (1)

h4ck7h3p14n37 (926070) | more than 7 years ago | (#19276735)

I could be mistaken, but I thought Connector/J 5.0 supported retrieving BLOBs as streams if you used the MySQL specific API and not just generic JDBC.

The latest production version of the driver is now 50-100 percent faster in most situations than the previous version. It also creates fewer transient objects than before, leading to better performance and even more stability. The driver now also supports "streaming" result sets, which allows users to retrieve large numbers of rows without using a large memory buffer. With newly added large-packet protocol support, the driver can send rows and BLOBs up to 2 gigabytes in size.

A client of mine insists on storing documents as BLOBs rather than simply storing URI's, so being able to stream BLOBs is a big plus for his application.

Re:The 8 reasons not to use mysql (3, Insightful)

TopSpin (753) | more than 7 years ago | (#19276961)

Does MySQL still truncate data that doesn't fit? I recall similar lists of criticisms posted here and elsewhere about MySQL and one of the entries is that numbers 'too large' or strings 'too long' for a given column are just silently whacked down to size. I thought then and persist in thinking that this behavior is pretty damning.

Re:The 8 reasons not to use mysql (1)

ryu1232 (792127) | more than 7 years ago | (#19277091)

Most CIO's would lump all of your reasons under: 5. Feature Set Maturity. Both of these were high level articles aimed at management, not at developers. This becomes even more evident with reason number 6: 6. Availability of Certification as real programmers are too busy coding to care about certs.

Re:The 8 reasons not to use mysql (1)

pr0xie (902743) | more than 7 years ago | (#19275947)

Product Maturity
By way of comparison, Oracle will hit the 30th anniversary of its first product shipment in 2009....

Mature or just long in the tooth?
If they are trying to maintain backwards compatiblity with older versions I would go for a newer fresher product.
And why is Perception of Scalability the only performance related complaint? The rest seem like excuses I hear from people who don't want to change.

Re:The 8 reasons not to use mysql (1)

Shados (741919) | more than 7 years ago | (#19276089)

Btw, #3 is actually a -crazy- big deal. DBMS like Oracle and SQL Server, for all their flaws, have incredibly powerful tools to integrate with legacy environment. There are NOT many ETL specialists around, and those that are free tend to charge premium for their services, making less well known products (3rd party) to be prohibitively expensive to use in the long run, so you're better off using the built in stuff. The commercial DBMS tend to be a blessing in that department.

Re:The 8 reasons not to use mysql (1)

Richard_at_work (517087) | more than 7 years ago | (#19276385)

I will agree with this, we are currently looking to migrate a legacy UNIX system (in a language you have never heard of, Sculptor, with data stored in what essentially amounts to a proprietary CISAM file with no database engine but can only be accessed by said language) to an MS SQL driven system (yes, we looked at everything, and MS SQL and .Net came out top, and thats coming from me, the company UNIX guru).

I can tell you right now, SSIS is fantastic for what we want to do, especially integrating with the above legacy nightmare.

Re:The 8 reasons not to use mysql (1)

Shados (741919) | more than 7 years ago | (#19276453)

Yup, I'm our company's SSIS guru (I don't know how I ended up there, I'm an asp.net developer, but oh well...), and it is great, we even use it to do some system orchestration between a bunch of legacy system, our business partners, DB2, and a bunch of other things (even using some custom SSIS tasks and components that I made). Its awesome.

In this day and age, the data engine itself is just one part of the equation.

Re:The 8 reasons not to use mysql (1)

HaMMeReD3 (891549) | more than 7 years ago | (#19276253)

I don't know if any of these have any merit, lets see
1. MySQL Uses the GPL
2. MySQL Doesn't Use the GPL
        - Those 2 cancel each other out, so lets toss em altogether, clearly the author failed logic class.

3. Integration With an Existing Environment
        - It's never an easy task to integrate anything into an existing environment, but lets see you install oracle on a debian server, or any other posix server not supported directly by oracle.

4. Product Maturity
      - The age of the product has nothing to do with the maturity of it, it also depends on the skill of the developers, there initial plans on how well they've scaled throughout time, and the amount of developers working on the project. An analogy would be to look at cars, the car with 100k is going to probably be in better shape then the one with 200k, regardless of how old either of the cars are. Also, the new cars have up to date technology in them and will stand the long haul better while operating more efficiently.

5. Feature Set Maturity
      - This is probably the most valid of them all,
6. Availability of Certification
      - It's available, it's expensive, and don't think you won't be paying the oracle dba or the ms dba craploads of money anways, if you want your devs to really really have it then send them to get certified, it's not like it matters all db's are relatively the same, get it relatively??

7. Corporate Considerations
      - Fuck corporate bastards, they clearly have no clue what they are talking about, leave the technical decisions to someone technical. If paying more for something makes you feel better go get a commercial license and a support license for mysql. A company being publicly traded or not has nothing to do with how appropriate a dbms is to your system. The only aspects for consideration are TCO and Technical limitations/strongpoints.

8. Perception of Scalability
      - What do peoples perception have anything to do with reality, crazy Christians perceive creationism is how the world was created 6000 years ago, it doesn't make it so. Even the author says so, sure it may be hard to change perceptions but it's not a reason why not to use mysql, it's more of a reason on why people don't.

Now I'm not gonna try and say mysql is the best dbms ever, just that this article is very "managerial" and it's the kind of stuff I'd expect to hear out of an incompetent boss.

Horribly written article (3, Insightful)

knarfling (735361) | more than 7 years ago | (#19276379)

It is painfully obvious from the article that this writer was or is a consultant. All of the reasons not to use MySQL are PHB reasons. Not one is based on actual abilities or inabilities of MySQL. He seems to be intent on agreeing with a position that he doesn't understand or didn't want to take. "...I'd be hard-pressed to tell a conservative IT manager making a platform decision for a mission-critical application based on this factor that he's doing the wrong thing." Yes, it does sound like he would be hard-pressed to tell any IT manager that the stupid decision he was making was the wrong thing.

The info at the end of the article says that he guides many projects based on MySQL, but it is hard to believe that he has ever used it. It sounds like all of his research was with PHB's or admins that have never really given MySQL a good try. A good admin knows both the pros and the cons of the software he uses, and hopefully, the good out weighs the bad. Many people that use or even swear by MySQL could give you some good reasons not to use it, under the right circumstances. Obviously, this guy could not find any. Either that, or he did his research in the wrong area.

I realize that this is the CIO magazine, and that some CIO's really are PHB's. However, Tina was able to write a good article on why a CIO should pick MySQL and give good reasons that were understandable to both technical people and PHB's. The only other conclusion I can come to was that Brent was trying to steer people towards MySQL and thought a badly written article against MySQL was the best way to do that.

Looking at the 8 reasons not to use MySQL... (4, Funny)

ezh (707373) | more than 7 years ago | (#19275761)

#1. MySQL uses GPL
#2. MySQL does not use GPL

close(rantPage);

System.out.println("Nothing here to see. Please, move along...");

How can the BSD be "too open"? (4, Insightful)

DaleGlass (1068434) | more than 7 years ago | (#19275783)

In these situations, if the BSD license of PostgreSQL is still too "open," a commercial license is preferred.
This is plain bizarre. How can a closed license be preferrable to BSD, when BSD is basically "do whatever you want with it", including closing the source?

Re:How can the BSD be "too open"? (4, Insightful)

Rycross (836649) | more than 7 years ago | (#19275817)

Obviously giving the author credit for originally writing the code is just too demanding.

Re:How can the BSD be "too open"? (3, Insightful)

RingDev (879105) | more than 7 years ago | (#19275841)

And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?

The 8 reasons are completely bunk, I thought I might actually learn something reading that article as we are about to increase our MySQL presence here, but that was a complete was of time.

-Rick

Re:How can the BSD be "too open"? (5, Insightful)

DragonWriter (970822) | more than 7 years ago | (#19276259)

And another gem FTA... "Whatever one might say about the strength of MySQL's backers, the fact that the company is not publicly traded means the financials are not required by law to be a matter of public record."

So we're going to have to trust the software company that won't show us their code, but will show us their books instead of the company that will show us the code, but not the books?!?


In business, this often makes some sense. The purchaser doesn't want to see and maintain the code, that's not their core competency. They want to be assured that, however, the vendor they get support from will be around to provide support in the future. So they are more concerned with the financials than the code.

Its just outsourcing in its original sense (before what used to be either "overseas outsourcing" or "offshoring" became the dominant definition): focus your company on its primary mission, and contract out for everything else.

Re:How can the BSD be "too open"? (1)

poopdeville (841677) | more than 7 years ago | (#19276533)

Very odd. Last I heard, MySQL AB was going public anyway.

Re:How can the BSD be "too open"? (1)

NevDull (170554) | more than 7 years ago | (#19275847)

Perhaps to avoid liability?

Some of his statements seemed to be about inclusion of the database in another product...

With the SCO v. Novell lawsuit on the front page, it makes me wonder if this is the underdeveloped idea he was getting at.

-Nev

Even so it doesn't make sense on its face (1)

Excelcia (906188) | more than 7 years ago | (#19276255)

Even if this is about tight integration of the RDBMS into a redistributable product, the statement about PostgreSQL doesn't make sense. Do what you want with it is always do what you want with it. The author is throwing arguments from different viewpoints out as if they ought to be arguments from one viewpoint. Sure, there are those in the open source community that say BSD is too free that all should be GPL, but that's hardly going to be an argument from a user perspective, no matter what the user wants to do with it.

Re:How can the BSD be "too open"? (1)

TemporalBeing (803363) | more than 7 years ago | (#19276223)

How can a closed license be preferable to BSD, when BSD is basically "do whatever you want with it", including closing the source?
Because they don't understand licensing. I've run into the same kind of thing with public domain software. Couldn't plug it in because they didn't understand that you didn't have to pay (or worry about legal issues with) public domain software, but were concerned support might not be there. Well - we had the source, but couldn't integrate it. So it the feature it would have supported got dropped.

Re:How can the BSD be "too open"? (1)

withears (881576) | more than 7 years ago | (#19276461)

Inclusion in some types of government projects is the primary issue. There are many hoops to jump through.

Reason 10 for not using (0, Redundant)

Anonymous Coward | more than 7 years ago | (#19275789)

Postgresql [wwwpostgresql.org]

Additional reason (1)

Phil246 (803464) | more than 7 years ago | (#19275801)

Not all database types are fit for all purposes. Relational databases for instance are bad for data mining/warehousing due to poor query performance but good for data entry due to high transactional performance

Re:Additional reason (1)

Threni (635302) | more than 7 years ago | (#19275889)

> Relational databases for instance are bad for data mining/warehousing due to poor query performance but good for data entry due to
> high transactional performance

Two words: Star Schema.

Re:Additional reason (2, Informative)

Shados (741919) | more than 7 years ago | (#19275955)

The more advanced RDBMS engines have OLAP/Datawarehousing support built in. For example, in SQL Server, thats SSAS, and it works wonderfully well, and is as integrated as it can be. Oh, one can argue that its technically a "separate" database, but from an installation, licensing and development point of view, they're one and the same. (Analysis Services also happens to be the market leader in that department...).

Thats just an example, and while thats Microsoft, I'm sure there are plenty of non-Microsoft equivalents for relational databases and olap cubes being integrated as one (and a half?) product.

Is that from Inman or Kimball? (1)

VampireByte (447578) | more than 7 years ago | (#19275967)

Do you propose using flat text files for data warehousing?

Re:Additional reason (1)

dedazo (737510) | more than 7 years ago | (#19276531)

Relational databases for instance are bad for data mining/warehousing due to poor query performance

Products like Hyperion Essbase have made this argument pretty much obsolete.

We won't miss you, Zonk (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#19275815)

I encourage everyone to disable Javascript for slashdot.org in his settings
and to disable the loading of images from other servers than slashdot.org as
long as that FUD spewing loser is wasting our precious time here.

The name of his own site says it all:

http://www.randomdialogue.net/ [randomdialogue.net]
[...]"I have random things to say."[...]

That is what I get when I read Zonk's articles. Random
sensation about bullshit only Zonk cares about. I guess
as a kid Zonk watched too much CNN where every sack of
rice in china is a important and threatening story.

I would rather read the whole duped SCO and Jack Thompson bullshit AGAIN
than any new Zonk story.


Forget it... it's TOO LATE! The market has already decided:

http://www.google.com/trends?q=slashdot%2C++digg&c tab=0&geo=all&date=all [google.com]

Reasons not to use MySQL? These are stupid reasons (5, Informative)

Tairan (167707) | more than 7 years ago | (#19275855)

Someone need's to slap this author with large trout. There are many reasons NOT to use MySQL, of which this article touches on only one. For example:
--Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed)
--Limit of 1024 current transactions ( MySQL bug 26590)
--Terrible performace when running MySQL Cluster
--Single threaded mysqldump exporting and importing (recently fixed in 5.1)
--Single threaded replication (making many changes? Don't count on it if you're running replication)
--Poor handling of subselects
--ineffecient ORDER by and GROUP BY
--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)
--better performance in 4.1.x

Let's also mention that 5.1 has been out in beta for years now. When is it ever going to ship? MySQL now is proclaiming fixes in 5.2, and 5.1 isn't even on the board to ship yet.

With all that, and more, I'm surprised this author could only come up with "it isn't made by Oracle" and "product mateurity."

*disclosure -- yes, I play with MySQL databases all day long in large high use production environments. MySQL is great for small systems, but there -are- some problems when running on large enterprise grade systems. It'll get there

Re:Reasons not to use MySQL? These are stupid reas (4, Insightful)

iknownuttin (1099999) | more than 7 years ago | (#19276019)

--Innodb scaling across multiple processors (MySQL bug ID 15815, still not completely fixed).....

The audience for both articles are for IT (upper)mangers. Most of your argument above would be better off for the technical lead whose doing the report for his immediate manager (maybe technical) who'll then give a report to the CIO or even to a manger below him that would say:

MySQL (GOOD)
Oracle (GOOD but expensive)
Excel (BAD)
Not that those managers inherently stupid (hope not), it's just that their more concerned with the bigger picture and the resultant budget.

Re:Reasons not to use MySQL? These are stupid reas (1, Informative)

drinkypoo (153816) | more than 7 years ago | (#19276227)

Don't forget there's other options. For example, Sybase and MS SQL Server (based originally on Sybase 10) are both faster than oracle and more compliant than MySQL.

Re:Reasons not to use MySQL? These are stupid reas (1, Informative)

Anonymous Coward | more than 7 years ago | (#19276519)

Bzzt! Thanks for playing!

SQL Server was based not originally based on Sybase System 10. It was much earlier than that. Thats why there is no CT-lib client interface for SQL Server, it didn't appear till System 10.

Whether either are faster then the big O depends on a number of factors. Traditionally, Sybase has been strong in the Wall St. type businesses where there is a very high OLTP workload.

Re:Reasons not to use MySQL? These are stupid reas (0)

Anonymous Coward | more than 7 years ago | (#19276605)

For example, Sybase and MS SQL Server (based originally on Sybase 10) are both faster than oracle and more compliant than MySQL.

That is debatable. Oracle is very good at high levels of concurrent updates & selects to the same data.

Re:Reasons not to use MySQL? These are stupid reas (2, Interesting)

Tairan (167707) | more than 7 years ago | (#19276263)

Yes, my arguments may be technical in nature, however the arguments in the article are worse than straw-man arguments. I'm surprised the author didn't mention that MySQL doesn't cost $20,000 per processor, therefor must be bad. Even given the intended audience (who, as you suggested, may not be extraordinarily technical) the pro-MySQL author did a much better job laying reasonable arguments.

You mention Excel jokingly, but I know some companies which maintain large databases worth of information inside of Excel (statistics on hundreds of applications for hundreds of devices on dozens of networks, reported daily ) because no one wants to write a script to input data into a database.

Re:Reasons not to use MySQL? These are stupid reas (0)

Anonymous Coward | more than 7 years ago | (#19276577)

you forgot one big one:

-- Views do not utilize the underlying table indexes

Re:Reasons not to use MySQL? These are stupid reas (2, Funny)

Ice Station Zebra (18124) | more than 7 years ago | (#19276803)

--Poor quality filesort algortythm (want to see your $20,000 dollar database server die?)

What does Al Gore have to do with this?

Re:Reasons not to use MySQL? These are stupid reas (1)

killjoe (766577) | more than 7 years ago | (#19276895)

Doesn't seem odd to be complaining about the speed of mysql cluster when the pgcluster web site hasn't been updated since 2005?

Re:Reasons not to use MySQL? These are stupid reas (1)

atomic777 (860023) | more than 7 years ago | (#19276923)

I agree with you that the author has not made a single insightful comment. But you are looking at MySQL as an Oracle DBA which isn't much better. I don't disagree with any of your points - they are all valid issues and are a result of MySQL not being used extensively on Big Iron in favour of clusters of commodity hardware. It comes down to the right tool for the job, and writing and architecting your application with the strengths and weaknesses of the DBMS in mind. Database neutrality is a great ideal, but for anything high-performance its unrealistic, and when taking an application written for one database and running it on another, downright unfair

e.g: Limit of 1024 current transactions (bug 26590). Why are you running so many simultaneous transactions on one box? Partition your data and take advantage of the fact that MySQL runs incredibly fast on cheap hardware and that you aren't limited by license cost.

If large web-based social networking sites with millions of hits per day can make MySQL work for their needs, it can work for you too. Don't expect your application written for Oracle to run flawlessly on MySQL without some tweaking, though.

Okay, 5-1/2 reasons not to use MySQL. (1)

Chas (5144) | more than 7 years ago | (#19275859)

Two of them are "The GPL can cause you problems."

Two of them are "Product Maturity".

And one is "Someone might think it's not scaleable". Possibly valid. Probably not.

What a fascinating argument. (1)

jd (1658) | more than 7 years ago | (#19275865)

It's almost impossible to say what the pros and cons are, when people usually stack or otherwise mix-n-match database products according to need. Even within the same organization, even within the same department, there will likely be servers that would benefit (if they're not already) and servers that would benefit from something else.

And that's before you get into "which MySQL are we talking about anyway" debates. There are multiple configurations for how the tables are stored, for example. Then there's MySQL vs. MySQL Max (which is a different product).

Oh, and the data is very important. Not everyone knows how to draw up an entity-relationship diagram, let alone build an optimized database from one, and different databases will lean towards different optimization methods.

The sheer number of permutations of configuring MySQL, of using MySQL, and of using MySQL in conjunction with other products, is so great that a simple list is useless. What would be more useful for people would be a sizable table which lists different types of scenario and different types of usage against different database engines.

Summary of both articles (0, Troll)

foniksonik (573572) | more than 7 years ago | (#19275873)

If you're cheap but adventurous and willing to risk a little maturity for a fast growing, easy to support DB, pick MySQL.

If you're a tight-ass who is insecure but is willing to spend money on something that's been around as long as you've been an adult or you've got an expensive DBA who's like this... pick Oracle (or some other proprietary RDBMS).

GasPerson (0)

Anonymous Coward | more than 7 years ago | (#19275899)

Tina is a GasPerson! Shes pissed off with MySQL because its not so gasy!

Easy To Use (1)

djsparhawk (1107233) | more than 7 years ago | (#19275953)

One of it's strongest points is that it's easy to use and manage. It's incredibly flexible and you don't need to be a DBA or hardcore programmer to work with it. As a Unix system admin I often find myself needing a small fast database to store a few bits of information for management tools. Yum install mysql && yum install php and off you go.

Re:Easy To Use (1)

froggero1 (848930) | more than 7 years ago | (#19276039)

[froggero1@lillypad ~]$ yum install mysql
bash: yum: command not found, apt-get rocks your world

while we're on it, vim > emacs, kde > gnome, apples > oranges, and blue > red.

Re:Easy To Use (1)

djsparhawk (1107233) | more than 7 years ago | (#19276117)

Apt-get is cool...
# apt-get install yum

I'm with you except !(apples > oranges)

Re:Easy To Use (2, Funny)

froggero1 (848930) | more than 7 years ago | (#19276353)

but oranges are sticky... and very inconsistant, sometimes you get really sour ones, no real warning sign of that. apples at least you know what you're getting... if it's squishy, it'll be gross and brown inside.

unless you include green apples in that debate, those ones can be pretty effin random. i don't like those ones much.

hmm... i need to do some more considering on this debate.

come to think of it, christmas oranges rock the house... so i guess if your comparing christmas oranges to green apples, then yeah, oranges > apples. but i think on average i'm still going to go with apples > oranges just based on sticky fingers and the potential of unexpected sourness.

Re:Easy To Use (1)

It'sYerMam (762418) | more than 7 years ago | (#19277023)

Sour oranges are the best though - the real problem is when they're all dried up and shrunken like an old man's face. Like the one I had today. Apples are more consistent though - but the mushy ones are still pretty vile.

Re:Easy To Use (0)

Anonymous Coward | more than 7 years ago | (#19277071)

Why bother? That's what SQLite and BerkeleyDB are for.

Better title (0)

Anonymous Coward | more than 7 years ago | (#19276009)

A better title would have been Dissagreements between a TodeRash and a GasPerson. Are these names real?

Who am I Supposed to be Rooting for, Here? (0, Flamebait)

hardburn (141468) | more than 7 years ago | (#19276049)

The MySQL supporter is raving about the large talent pool of MySQL developers, and the detractor is raving about the GPL.

Yes, there are lots of people who have "MySQL" on their resumes, right next to "PHP". They're all clueless ninnies. If they weren't clueless ninnies, they would have chosen PostgreSQL years ago. Yes, you can hire clueless ninnies on the cheap. That's not the point.

What does the license have to do with it? I can conceive of a project where I'm going to be bundling up a database with my application and selling it. Why would your code be so deeply integrated with the database that you legally have to sell the whole thing under the GPL?

RIDICULOUS! (1)

erroneus (253617) | more than 7 years ago | (#19276071)

If 1 and 2 are both valid reasons, then all RDBMSs are just as unacceptable for use depending on which of the two reasons fit the situaiton. For that matter, all software... everything... everyone!

No seriously, I don't get it. Why is being under the GPL a bad thing?

lame "bias" argument (2, Insightful)

CodeMunch (95290) | more than 7 years ago | (#19276087)

FTFA:

One trend I have observed but for which I have no hard data is that formally trained DBAs tend to prefer a proprietary RDBMS such as (most commonly) Oracle. I suspect that those with formal training and experience as a DBA (rather than as a software developer) tend to have a bias toward proprietary systems.

Due to tue relative low incidents of formally trained Oracle DBA's being mauled by Tigers, you could also infer that formal Oracle DBA training will also protect you from Tiger attacks. (To re-use & mash up that old cliche).

What a lame argument. Of course there may be some bias, but the fact is that: Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.

To be able to manage these systems efficiently & keep a "Q9" system up & running, the formal training certainly does help but I would argue is not required as the documentation is pretty damn helpful unless you get one of those wonderful ORA-600 errors (is that the magic "WTF" Oracle error? I can't recall).

Sure - the woo of mega bux will entice many into Oracle DBA training but the weaker resources fall off quickly. You can't fake it when your production system is down.

IANAODBA

Re:lame "bias" argument (2, Interesting)

drinkypoo (153816) | more than 7 years ago | (#19276265)

Oracle kicks every other RDBMS at pretty much everything: Stability, speed (optimizations up the wazoo), features, consistency.

Last time I checked, DB2 was more scalable than Oracle (less performance hit as you stuffed the database) and both Sybase and SQL Server were faster.

Re:lame "bias" argument (3, Informative)

dedazo (737510) | more than 7 years ago | (#19276483)

Last time I checked, DB2 was more scalable than Oracle

That depends entirely on the platforms you happen to run them. DB2 on NT (what used to be called "UDB") is a joke; DB2 on OS/390 is pretty much what defines a "big-iron" database. Oracle on NT is nowhere near as good as it is on Solaris. But Sybase on NT is actually quite good - almost as good as SQL Server on the same hardware. Sybase 12.x on HP-UX is also quite good.

Re:lame "bias" argument (1)

CodeMunch (95290) | more than 7 years ago | (#19276947)

You are likely absolutely correct about DB2 - I've never had the pleasure of using it.

In datawarehouse environments & app environments I've always seen more Oracle than SQL server. For speed/stability I've always had more success with Oracle but have no qualms with SQL Server - it is mighty fast and easy to use(ducks & dodges eggs & rotten tomatos) but I've queried sql server to a crawl more often than I ever have an Oracle db.

We have an instance of Sybase where I'm at now but haven't given it a thorough thumping yet.

I guess my original comment should have specified "in general". Anyway, the point is, There are a helluva lot more reasons than "formal training" for choosing Oracle more often than others.

Lame comparison (1)

EatAtJoes (102729) | more than 7 years ago | (#19276107)

Even though the negative article is imperfect at best ("Perception of Scalability"??), at least it actually comes from someone who seems to understand the world of databases.

The positive article, though, is ridiculously weak, riddled with IT-journalist misconceptions (AJAX is a language? Scalability is achieved via ... stored procedures??). As such it's an unfair match.

On the positive side, what about:

1) MySQL is FASTER. Cite some research of the shootouts. MySQL always does well.
2) MySQL is OPEN SOURCE (at least the negative article addressed this, although in a stupid fashion). Journalists don't seem to get how much better it can be to work with a product with open source, when tracking down bugs, or merely finding good resources (docs, howtos) on the web -- aside from the TCO free-as-in-speech-and-beer aspects.

Re:Lame comparison (1)

larry bagina (561269) | more than 7 years ago | (#19276737)

MySQL is fast for simple queries. I've seen a lot of anecdotal evidence of mysql sucking for more complex stuff (multiple table joins, large volume sets, etc).

Example [pm.org]

We've been running our web site on a MySQL 4.0 database with MyISAM tables, and are currently in the process of migrating to PostgreSQL 8.1 purely on the basis that it's faster. We have two queries that our site uses that, under MySQL 4.0, take over 20 seconds to execute on a dual 2GHz G5 XServe. Some experimentation showed that under MySQL 5.0 these same queries would execute in about 6 seconds. PostgreSQL on a single 1.25GHz G4 machine would execute the same query in just 4 seconds. This is not all that complex a query - it only involves 4 tables.

Where PostgreSQL really shines above MySQL is when multiple copies of this query are being handled at the same time. If there's 3 of these queries running concurrently then Postgres will deliver its results in about 12 seconds, i.e. 3 times the amount of time. Three of these queries under MySQL however results in them taking about 3 minutes to complete. The performance of MySQL just continues to degrade if you add on more queries - run about 8 of them together and you'll be waiting over an hour for the results. PostgreSQL just scales up as you would expect - 8 queries will complete in 32 seconds.

MySQL makes sense... sometimes (2, Informative)

R3d Jack (1107235) | more than 7 years ago | (#19276141)

Many applications need a small to medium size database that contains important but non mission-critical data. MySQL is perfect for those applications. No licensing hassles, no funds requests, no major administrative overhead. I don't have enough experience with MySQL to recommend it for a really critical database, but we do have plenty of need for smaller databases that we can set up quickly. I certainly don't see spending a lot of money on SQL Server (which we are doing) or any other big commercial server to run a bunch of small databases.

Re:MySQL makes sense... sometimes (1)

Shados (741919) | more than 7 years ago | (#19276279)

Thats a bit (but not completly) less true now than it was a few years ago. Most of the commercial databases now have free offerings and can be administrated by a child. If you're on Linux or something, then its nice, its probably just a command line away to install it and then its perfect, yes. On Windows however, might as well use SQL Server Express or something.

Re:MySQL makes sense... sometimes (1)

davidkv (302725) | more than 7 years ago | (#19276455)

Then again, loads and loads of projects are using MySQL. The stuff about MySQL not being good for them might be right, but the abundance of projects/code using MySQL is quite telling.

Arguing about it is like arguing about favorite colors, and wanting the same color on everything, always.

Re:MySQL makes sense... sometimes (1)

Shados (741919) | more than 7 years ago | (#19276507)

You're totally right and correct, sorry if I wasn't clear in my point. I just meant that "Needing a small DB for a small project, and it has to be free" isn't one of the arguments FOR mysql anymore. There are other arguments of course, but for the SAME reason probably 2/3rd of Oracle users really do so because its "buzz word compliant", and really don't need Oracle, a LOT of MySQL users do it because its all they know and so many people use it.

Funny enough, if everyone used the right DB for them, the numbers would probably be similar to what they are now, just reversed (a bunch of MySQL user should switch to Oracle, MS SQL, etc, and a bunch of Oracle and MS SQL addicts would use MySQL...)

The article is disappointing. (1)

RedElf (249078) | more than 7 years ago | (#19276201)

If you're going to choose 8 reasons to not use a product then at least back up those reasons. All of the assertive tip toeing is boring, and tells us you don't really think those reasons are all that valid yourself.

#2 is not an issue with enterprise applications (2, Informative)

anomalous cohort (704239) | more than 7 years ago | (#19276431)

If you want to distribute the license for the database along with your own project, your project must either be licensed under a similar compliant license, or you must pay for a commercial license.

This article comes from CIO website so I think that it if fair to say that they are most interested in applications for the enterprise. Enterprise applications don't bundle the database. They may require a certain database vendor product/version or a small set of database vendors but they don't bundle the database with the application. This is true whether or not you use SQL Server, DB2, Oracle, MySQL, or PostgreSQL.

IANAL, but IMHO there is no legal restriction to selling a commercial, closed source application that requires MySQL as long as you don't include the MySQL application with it. This isn't a problem for enterprise applications because businesses that need such applications already have sufficient IT experience to run the vendor specific database that they are going to accept. If a company doesn't have sufficient IT experience to do this then they are going to have to go the SaaS route. Their are not going to be able to manage the application even if it did come bundled with a vendor specific database product.

Re:#2 is not an issue with enterprise applications (2, Insightful)

Evets (629327) | more than 7 years ago | (#19277105)

Agreed. Another point to be made is that many enterprise applications use the database layer as a storage mechanism and either don't optimize for the database platform or don't take full advantage of optimization capabilities on individual platforms.

When it comes down to it, most enterprise apps would not see a significant performance shift in either direction based on platform and in those situations it is better to go with the database vendor with which your staff has the most experience. Enterprise applications rarely support MySQL or even Postgres except via slow ODBC connectivity.

For those applications that do maintain extraordinarily large data sets and see very high traffic levels there is still the factor of familiarity and experience to deal with. For a cost differential adding up to 100s of thousands of dollars in those scenarios it is unwise to not to at least take a look at open source platforms.

I could go into which platform I prefer in different scenarios but it's really not a very black and white thing. From a CIO perspective the best thing that you can do is to push software vendors to support open source DB platforms out of the box.

Invalid use of the GPL? (2, Insightful)

dthulson (904894) | more than 7 years ago | (#19276479)

I'm a little concerned about MySQL and the GPL... Here are some thoughts of mine about MySQL AB and the GPL: http://www.crownandcutlass.com/blog/2007/01/15/mys ql-ab-and-the-gpl/ [crownandcutlass.com]

The link I have there for the MySQL internals doc seems to be invalid... It has moved to here: http://forge.mysql.com/wiki/MySQL_Internals_Client Server_Protocol#Licensing_Notice [mysql.com]

Here is a quote:

Because this is a GPL protocol, any product which uses it to connect to a MySQL server, or to emulate a MySQL server, or to interpose between any client and server which uses the protocol, or for any similar purpose, is also bound by the GPL. Therefore if you use this description to write a program, you must release your program as GPL.
I don't think that's a valid use of copyright, but I'm not a lawyer. Can anyone explain to me how that's a valid use of the GPL?

Supports Cutting Edge Technology (3, Insightful)

BrandonReese (1055794) | more than 7 years ago | (#19276485)

MySQL comes prepared to support all the most popular Web 2.0-ish languages, such as Ruby, Ajax and, of course, PHP.

I've got the php_mysql.so library, but I can't seem to find the MySQL library in my Ajax installation... Oh wait, ajax isn't a programming language. I'm sorry little things like that really get under my skin (e.g calling the CPU "the hard drive", "I've got the Internet on my computer", calling excel spreadsheets databases). In case the author of the article didn't know, postgreSQL also comes prepared to support Ruby, and PHP.

I also didn't see where they listed phpmyadmin as a reason to use MySQL. Seems like they always use that as one of the reasons.

8 vs 5? (0)

Anonymous Coward | more than 7 years ago | (#19276527)

I don't even have to RTFA to know that 8 is more than 5, therefore I obviously shouldn't use MySQL

I tried to pay attention. I really did. (2, Interesting)

philovivero (321158) | more than 7 years ago | (#19276557)

But some +5 commenter pointed out what the 8 points against were, and they sounded lame. Another commenter actually listed 8 real problems with MySQL. But no matter how you slice it, the biggest, baddest, most ass kicking websites on the planet* are powered by MySQL. So... uh... deal with the reality. MySQL isn't going away.

* Google.
* Yahoo.
* Digg**.

** Yeh, I'm the Digg DBA.

Re:I tried to pay attention. I really did. (1)

Shados (741919) | more than 7 years ago | (#19277377)

I wouldnt bet my soul on it, but I was under the impression Google mostly used MySQL for internal system uses, not for their actual customer facing services...

Seriously (2, Insightful)

Vexorian (959249) | more than 7 years ago | (#19276699)

For the article writer a product's maturity solely depends on its age.... *thumbs down* I wanted an interesting read and got this?

content-free article (1)

nsayer (86181) | more than 7 years ago | (#19276725)

It was enough that on the 3rd or 4th page of the '8 reasons not to' article that they used the PHB acronym, but then explained it in parenthesis. *TWEEET* Gene police! Out of the pool!

Scaling, robustness, etcetera. (4, Informative)

seebs (15766) | more than 7 years ago | (#19276941)

I recently started looking into databases, and I asked a bunch of friends. All the experienced ones gave roughly the same advice: If you don't have time to read directions, just throw something together with MySQL. It'll be okay. PostgreSQL would be better.

So I took the extra ten minutes, and I'm pretty happy.

Every large site I know of that uses MySQL has had scaling problems of one sort or another under load, usually to do with trying to handle multiple writes to the database. At least a few people have simply swapped in PostgreSQL and seen problems disappear instantly. One friend did performance testing, where what he found was that MySQL was faster for small sets of clients, but that it slowed down faster, and that for largish N, he couldn't get it complete the test on the available hardware, but PostgreSQL just ran.

Having set up both a few times now, and having debugged problems with both, there is simply no way I'd use MySQL given any choice at all. It runs, but it feels accreted rather than designed. I know, Cathedral and Bazaar and all that... But there are times when you really do want the feeling that someone considered something up front.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>