Augusto Bott at Pythian recently posted a good entry detailing some differences between Oracle and MySQL from a MySQL DBA’s perspective, From MySQL to Oracle: A Few Differences. My viewpoint is exactly the opposite, I know Oracle extremely well but I have a lot of learning to do with MySQL.
Augusto ran into a SQL*Plus issue, where it is less than obvious where a SQL syntax error is. He could get around this error by using SQL Developer, Oracle’s free SQL Development IDE. SQL Developer can connect to and browse MySQL databases in addition to Oracle and SQL Server.

A good article on Motley Fool, discusses Oracle’s outstanding financial performance. I still think Oracle needs to do more to counter open source offerings but numbers like these are hard to argue with.

The numbers continue to speak for themselves at Oracle. First-quarter sales advanced 26% and earnings grew 28%. Better yet, new software license revenue grew 35%, well ahead of the 23% growth in license updates and product support and the 25% improvement in services revenue. Management explained it by noting that its installed base is growing, which only leads to lucrative product updates and related services down the road.

It looks like buying out the competition is having a doubly good effect.

Read Partitioning In MySQL, Part 1 before reading this post.



Partition pruning is the most critical performance component about partitioning. Partitioning can ease management of your data (for example the ability to just backup or restore a single partition or the ability to drop a no longer needed partition) but the main reason people add partitions is for performance.



Pruning helps performance by only reading the partitions that need to be read for a query. For example, if you have a table range partitioned by year that has partitions for the years 2000 through 2010.

I was browsing around the MySQL web site tonight and ran across some free webinars (recordings). Seeing as how I once did a podcast on Oracle partitioning, one webinar that jumped out at me was Partitioning in MySQL 5.1 and onwards.



I didn’t even know MySQL did partitioning. Here is a description of the webinar:




In this webinar we will provide further insight into MySQL partitioning, including:

• Introduction to MySQL Partitioning
• Linear Key Partitioning
• Partition Function
• Partition Options
• Information Schema for Partitions
• EXPLAIN PARTITIONS
• Partition Management
• Partition Pruning
• Partitioning and NULL Values
• Partitioning Implementation
• Partitioning for MySQL Cluster
• Future Roadmap for Partitioning
• Partitioning Limitations in 5.1

Sounds good. It’s a good presentation but kind of slow.

I just found out that MySQL 6.0 with the Falcon Storage Engine is available as Alpha. Falcon adds ACID compliance, tablespaces and performance improvements. It’s supposed to also simplify administration but I’m not sure how MySQL can be simplified. It’s pretty simple now.
I’ve always thought that the ability to swap out the storage engine is the best feature of MySQL. It reminds me of the replaceable database drivers from my clipper days in the late 80s and early 90s.

From my reading about Falcon, it looks like one advantage will be the fact that Falcon has been engineered to take advantage of 64 bit architectures and large memory caches.

I am reading up on MySQL Proxy and find it to be very interesting. It looks like the proxy is a network layer between clients and servers. A client may think it is connecting to a single server but in reality, the client’s query could be running against multiple distributed servers.

Another nice feature is the ability to monitor and secure data at the query and result level. A client can send a query and the proxy can log that query. When the results come back, the proxy could strip out data (or mangle it) before it goes back to the client.

Feature comparisons, in addition to being somewhat lame and almost always biased, are very dependent on versions. If you throw in performance considerations, they are also dependent on hardware and configuration. Even so, I like to read comparisons, for historical information if nothing else.
Here are some comparisons that I have found. I make no recommendations or even commentary about them. Read through them as if you are a database anthropologist. Dig for the nuggets that increase your existing base of knowledge but remember that a human, probably one with an agenda, put these comparisons together.

Have you ever wondered why you should choose one open source database over another? What features would make the most sense for your Organization? Maybe you’re a developer looking to learn a database and can’t choose where to start?

The folks at PostgreSQL have put together a wiki, Why PostgreSQL instead of MySQL. It’s, by no means, complete at this time but it is a good start.
The wiki is not editable by the public but it is open for reading. The wiki entry compares PostgreSQL 8.1 and MySQL 5.0.