MySQL Outpacing Oracle In Wake of Acquisition

snydeq writes "Results from the 2010 Eclipse User Survey reveal interesting trends surrounding open source usage and opinions, writes InfoWorld's Savio Rodrigues. Linux usage among developers is on the rise, at the expense of Windows, and MySQL has pulled ahead of Oracle, by a factor of 3-to-2, as the database of choice among Eclipse developers. 'The data demonstrate that fears surrounding Oracle's control over MySQL have not resulted in lower use of MySQL in favor of an alternative open source database,' Rodrigues writes."

Comments

Oh, bruther

[hey!]

What a non-story.

You use Oracle because you *have to*. Not because it is pretty.

Saying MySQL has pulled ahead of Oracle is like saying that claw hammers have pulled ahead of pneumatic hammers mounted on giant excavators.

Re:Oh, bruther

[drinkypoo]

You use Oracle because you *have to*. Not because it is pretty.

Similar things have been said about MySQL. It's a de facto standard, which many view as being quite unfortunate in light of the competition.

Saying MySQL has pulled ahead of Oracle is like saying that claw hammers have pulled ahead of pneumatic hammers mounted on giant excavators.

Since MySQL got clustering it became capable of replacing Oracle in certain contexts. I don't have a tool-related metaphor handy but there are actually cases in which the comparison might not be so ridiculous.

Re:Oh, bruther

[14erCleaner]

Furthermore, this is a survey of Eclipse users, not all database users. Developers using a free framework prefer a free database. Surprise!

Re:Oh, bruther

[Score Whore]

Don't get me wrong, if you write queries that are exactly how Oracle likes them it's fast and solid, but I've worked with SQL Server, PostgreSQL and MySQL as well and the management tools are easier, the query optimizer is more flexible and the error messages more helpful. Particularly that Oracle wants queries their way, I've reused queries that run in seconds on SQL Server and take minutes on Oracle but hardly if ever the other way around.

Treating the database as a black box is the problem, not the solution. At least if you're dealing with more than trivial amounts of data with trivial queries. It is amazing how many developers are shocked that their app, that worked perfectly on their desktop against their own personally installed database with, gosh, nearly two megabytes of data, completely falls over when deployed into against the eight terabyte production database.

In other words, a database isn't a replacement for thinking.

Re:Oh, bruther

[Kjella]

Well doh, that would be comparing blueberries to watermelons. But I've been been working with a product that supports both SQL Server and Oracle so production databases of about equal size, equal hardware and equal content. I develop queries to show something at one client site, then reuse it at a different client site with a different database system. In short, two equally smart database systems should perform about the same. What I'm saying is that in my experience Oracle often generates very poor execution plans, and fiddling with it to make Oracle do it "right" that others manage just fine on their own is not treating it as a black box, it's tedious and unnecessary micromanagement to overcome product shortcomings.

Re:Oh, bruther

[hey!]

In short, two equally smart database systems should perform about the same.

Bingo. Ergo, something is wrong with your Oracle installations.

I've done the same, supported an application that is available for MS SQL, Oracle and Sybase Sql Anywhere. MS SQL and Oracle blow SQL Anywhere out of the water in performance, but in most situations you couldn't tell the difference.

From a developer's POV, SQL Anywhere was in most cases a pleasure to work with, Oracle was acceptable in most cases and outstanding in a few, and MS SQL was a horrible PITA. MS SQL doesn't even provide you with a utility to get a human readable dump of the transaction log, much less any way to use the transaction log in a complex recovery (unless you fancy working with page addresses). When a customer does something really stupid, and calls you up saying, "please, please make it like that never happened," it's as easy as rolling off a log in Oracle, practical in SQL Anywhere and not worth doing in MS SQL.

postgres didn't do so badly

[MagicMerlin]

11%...edging out ms sql server! Postgres 9.0 has built in replication -- it will be interesting to see how that affects its share of the open source db space.

Re:postgres didn't do so badly

[MagicMerlin]

Postgres has traditionally had lousy replication options. This of course is going to change with 9.0 hs/sr. Older versions of postgres (pre 8.x) had some operational difficulties that made it an awkward fit for high transaction load web environments. Now that those downsides are pretty much eliminated, it's about the best general purpose sql database out there -- it has many niceties/features that are rare/non-existent elsewhere. Transactional ddl for example.

The title is misleading

[jitendraharlalka]

It is definitely great to know that MySQL is doing great even in Oracle's hands and even Linux is growing in Eclipse User Survey. However, the title of the post is totally misleading as it is merely based on Eclipse User survey and that too with merely 1696 users. Nearly 40% of the respondents came merely from Germany and France (The survey believes this shouldn't bias result but we really have no reason to believe their assumption).

Re:Some POed sales guys

[nxtw]

I don't think there are many MySQL users that would have even considered talking to an Oracle sales representative.

Re:State of the Databases

[FlyingGuy]

You could not be more wrong about:

Oracle needs to drop the high prices, the competition in the market now doesnt allow them to have those prices.

An this is why...

It's called support. One of the major reasons I recommend Oracle to clients who need maximum uptime and downtime is just not an option is because of the world class support Oracle provides. If you are a licensed Oracle site you have support 24/7/365 no matter what time zone or country you happen to be in. If you pick up the phone and say those magic words, "I'm down" the calvary is not just coming over the hill they are at your door. Guess what that kind of support costs a lot of money to provide.

In our race to the bottom of the price bucket lots of things have to be cut and guess where they cut first, you guessed it, in support. With Oracle support you do not get script readers in India or the Philippines you get an Oracle engineer on the phone ready to tackle the problem with you until the problem is solved and they will bring in whatever other resources are required.

MySQL is a wonder database that does what it does very well, but would I put it up in a mission critical bit of infrastructure? Not on a bet. Those companies that have, eg: Sales Force and the like have had to hire LOTS of engineers/developers to handle MySQL in big installations and that costs even more.

Postgre has no such level of support either. So when you missions critical DB goes south either you better be able to fix it or you had better have a lot of friends you can wake up in the middle of the night.

Re:Nice to them

[jazzkat]

This is because you're using MySQL to develop on. MySQL allows all manner of illegal hostnames and other bad programming practices in the name of "making things easier" for people who don't know any better.

If you developed using Postgres, or another more compliant database, most of these problems would go away.

Re:Nice to them

[TheRaven64]

Most of the time, people use a database because they care about their data. That's really the point of a database - to provide a persistent store for a load of data that is as difficult as possible to accidentally break. Ideally it should be fast as well, and allow you to access the data in complex ways.

A number of rules in SQL are quite pedantic for precisely this reason. If you enter something invalid then the database could guess what you meant, and might even be right 90% of the time. The other 10% of the time, it would be silently corrupting or destroying parts of your database, or maybe just discarding part of the data that you thought was persistently stored.

MySQL deviates from standard SQL in a number of ways, allowing things that are wrong to do something. Exactly what 'something' is depends on the version of MySQL that you are using.

Basically, using MySQL is like running with a load of error checking disabled. Sure, it's irritating that your code compiled with a load of assert() statements keeps breaking with an assert failure, but generally it's better to see the error and fix it than to deploy a production system after just commenting out the assert() line.