changuno wrote:
Hi folks,
Read a blog which states 50 things to know before migrating from Oracle to
MySQL. Any comments on this?
... list snipped ...
MySQL was never designed to be a clone of Oracle (the database). We
have distinct differences in design and implementation that make us a
wonderful product to use as a "general purpose database".
I agree with the other respondent: If your project cannot possibly
function without one or more of the features that MySQL does not
provide, then don't use it.
However, our feature set has been and continues to be complete and
powerful enough to be the storage engine behind some of the internet's
most popular and heavily visited websites. I can see reasons why some of
the feature differences (aka overhead) may be useful in certain use
cases. However there is a long history of popular usage that indicates
that not everyone, or every project, requires the full set of features
you describe:
http://www.mysql.com/customers/
I agree with some of the points you make and we are working to implement
some of the features you mentioned. On the other hand some of those
"deficiencies" that you mention are specific strengths of the MySQL system:
23. There are fewer and less sophisticated tools for administration.
MySQL doesn't need them. That alone should tell you something about our
reliability.
24. There is no IDE and debugger that approaches the level of
sophistication you may be accustomed to. You’ll probably be writing your
stored procedures in a text editor and debugging them by adding
statements that insert rows into a table called debug_log.
Again, this is an indication that you don't *need* complex tools or a
GUI to work with MySQL. The simple solution is often the better
solution. It also allows you to develop for your server from practically
anywhere, not just a machine where your GUI tools are installed.
25. Each table can have a different storage backend (”storage engine”).
Yes, we absolutely allow this.
Each engine brings a certain strength to the storage and retrieval
solutions you can create with MySQL. We explicitly recognize that there
is no "one size fits all" approach that meets the needs of every
problem. This also allows for special-purpose solutions to be integrated
into MySQL:
http://solutions.mysql.com/solutions/?type=29
28. The default storage engine is non-transactional and corrupts easily.
True: MyISAM is does not require the disk and CPU overhead of tracking
changes transactionally. False: In my experience (I do work for Support)
MyISAM is rarely corrupted. I dispute this claim.
29. Oracle owns InnoDB, the most advanced and popular storage engine.
As of yesterday, this became a moot point. Oracle now owns MySQL, too.
http://www.oracle.com/us/sun/index.htm
34. There are no integrated or add-on business intelligence, OLAP cube,
etc packages.
False. Please see:
http://solutions.mysql.com/solutions/
38. The number of joins per query is limited to 61.
True, but why is this a problem? Do you frequently (or ever) need to
join more than 61 tables into the same query? If you do, I propose that
you need to revisit your schema design choices or review how you write
your queries. In this case, I think we are discouraging bad practices.
39. MySQL supports a smaller subset of SQL syntax. There are no
recursive queries, common table expressions, or windowing functions.
There are a few extensions to SQL that are somewhat analogous to MERGE
and similar features, but are very simplistic in comparison.
Again, the vast majority of data storage and retrieval activities do not
require these features. If you absolutely cannot function without them,
then do not use MySQL.
44. There is no built-in promotion or failover mechanism.
Again, we have no "one size fits all" approach to this. We do not assume
to understand your business processes nor do we want you to design your
process to support our procedures. The failover process is yours to
design and implement as you see fit.
45. Replication is asynchronous and has many limitations and edge cases.
For example, it is single-threaded, so a powerful slave can find it hard
to replicate fast enough to keep up with a less powerful master.
Yes, it is asynchronous. This is a distinct advantage to many read-heavy
applications and it allows MySQL to scale out better than most, if not
all, other RDBMS systems.
http://www.mysql.com/why-mysql/white-papers/mysql_wp_scaleout.php
http://www.mysql.com/why-mysql/scaleout/booking.html
49. There are no sequences.
Please explain why auto_increment cannot meet this same need? Why have
the overhead of two ways of performing essentially the same function?
This is just one less way to confuse your design.
--
Shawn Green, MySQL Senior Support Engineer
Sun Microsystems, Inc.
Office: Blountville, TN
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
