July 25, 2012

SQL Server to MySQL migration — why?

Oracle wants you to help you migrate from Microsoft SQL Server to MySQL. I was asked for comment, and replied:

Am I missing anything?

Comments

12 Responses to “SQL Server to MySQL migration — why?”

  1. Daniel Abadi on July 25th, 2012 8:53 am

    I don’t think the migration is from SQLServer/Windows to MySQL/Linux. I think it’s from SQLServer/Windows to MySQL/Windows.

  2. Curt Monash on July 25th, 2012 10:15 am

    Good catch, Dan!

    That makes even less sense as is. On the other hand, it could be an effective midpoint for a move to MySQL on Linux.

  3. Scott Sullivan on July 25th, 2012 10:45 am

    There is a richer ecosystem of scale-out solutions for MySQL. According to the Azure rep I spoke to last year, the only options on MSFT are buying a bigger instance or sharding.

  4. Zack on July 25th, 2012 11:28 am

    Perhaps we’re an outlier here, but our shop is completely linux/apache/tomcat/etc. EXCEPT for MSSQL server. We had a choice of Oracle or MSSQL to meet the db requirements for a piece of software we had purchased, and MSSQL was mucho cheaper than Oracle, so we went with it.

    That was 10 years ago, and we no longer use the software in question, and as the story goes, once you’ve got something you tend to use it, so even though the rest of the stack is decidedly not-MS based, we’re stuck now with MSSQL, and we’d LOVE a way to take it out back and shoot it.

    Why? Well, we’ve reached a point where our next upgrade (from 2005->2012?) will be extremely costly as we’ll need to go from std edition to enterprise edition ($100k+) to meet our memory and clustering requirements.

    Next, it causes us all sorts of development headaches since my development staff (again, all linux) cannot have local database copies to run against. We have a large local dev/qa database instances, but run into issues constantly with devs stepping on each others toes on those instances. MSSQL express limitations rules it out, and while I guess we could get web version licenses for them, it’s just a pain to have a disparate stack like we’ve got (and yes, it’s our own damn fault), and a TOTAL pain to work with MS licensing, working with them is a Kafka-esqe nightmare.

    I have run into people using the express and web edition licenses in very creative ways. One mobile payment processor is striping all their data across multiple Windows VMs with MSSQL express using a consistent hashing algorithm and transaction router, with N-replicas and near zero cost for their .Net application.

    That being said, MSSQL has been pretty good to us, it runs well with little or no expert tuning, and generally behaves sanely. If it weren’t for our stack and our dev needs, I’d like it more. The other factor playing into this frustration is we’ve been working extensively with Postgresql on other project and it has been a real pleasure (except for the admin tools).

  5. Larry Dooley on July 25th, 2012 1:19 pm

    In the beginning it was a pretty simple split SQLServer/Windows easy to use, low price point won’t scale to really big apps. Oracle/Linux/Solaris difficult, expensive will scale.

    SQLServer is still a pretty good DB limited by a OS that every time I look at has some new scripting language – now it’s powershell. And SQLServer is getting complicated read the 2012 version documentation. And as you grow it gets more and more expensive

    That said the stack change would be a big expense and really daunting to do. You’d bleed people spend resources making the switch and what would be the net benefit? Not to mention risk – such major moves can often result in big problems. CIO’s who undertake this either must be willing to tolerate big risks or have an either more unpleasant choice by sticking with it.

    I think this is just Oracle torturing Uncle Fester(Balmer)

  6. Jason on July 25th, 2012 1:42 pm

    In all of the shops that I have been in, the database code is a large, if not the largest codebase. The ETL, stored procs which wrap or simplify the data model, maintenance scripts, data validation, idiosyncratic fixes, etc.

    Recreating the wheel in any of these environments on such a fundamental part of the application would never be trivial.

    To the previous poster: Try using powershell.

  7. Dan on July 25th, 2012 4:51 pm

    @Zack, just use the SQL Developer edition. It has the same features as Enterprise, and I beleve if the users already are licesnsed (for using the DEV edition in Dev/QA) is free. Dev can be installed as many times you want, but $35 per dev user.

  8. Curt Monash on July 25th, 2012 7:39 pm

    Scott,

    Hence my comment about internet companies and the like. :)

  9. Hubi on July 26th, 2012 2:25 am

    There are more reasons for a company to want to migrate the other way.

    1) Once you are in Oracle’s playpen then it’s just a short step until Larry has you over the barrel and paying for his next yacht or island.

    2) Every time you hear about a SQL injection it’s MySQL involved. Oracle, patching and security is not a strong point.

    http://www.microsoft.com/sqlserver/en/us/product-info/migration-tool.aspx#MySQL

  10. Damir on August 2nd, 2012 5:59 am

    The price can certainly be an important factor. For example, a friend’s company installs MySQL on customers’ servers. That’s hundreds of servers. If he would be using SQL Server, price for his software would skyrocket and he wouldn’t be able to server the customer segment he does (some multinationals, many small businesses, but also many many shops with just a few employees).

    When I worked there 10 years ago, the obvious need for conversion software and database independence made me create database conversion company. See http://www.spectralcore.com and http://www.sqltran.com. Our tools are pretty neat. SqlTran can even translate thousands of procedures in just a few seconds. :)

  11. anon on August 2nd, 2012 7:55 pm

    Yeah, I’m really confused by the issue identified above. Just have a VM for each developer with MSSQL Developer Edition on it. If you are clever about it, someone in the group can post the VM in a central place with a known schema, and when there are schema changes they can post a new one and people can us vConverter or whatever to bring them to their dev box and run whichever schema/VM they want to.

    I actually really like MSSQL if you are under the size where you need to scale-out, but like most on this thread, have a hard time with the OS its associated with. I’ve always wanted SSAS on Linux, too.

  12. Notes, links and comments August 6, 2012 | DBMS 2 : DataBase Management System Services on August 6th, 2012 1:12 am

    […] Pros and cons of Microsoft SQL Server were explored after I opined about SQL Server to MySQL migration. […]

Leave a Reply




Feed: DBMS (database management system), DW (data warehousing), BI (business intelligence), and analytics technology Subscribe to the Monash Research feed via RSS or email:

Login

Search our blogs and white papers

Monash Research blogs

User consulting

Building a short list? Refining your strategic plan? We can help.

Vendor advisory

We tell vendors what's happening -- and, more important, what they should do about it.

Monash Research highlights

Learn about white papers, webcasts, and blog highlights, by RSS or email.