If you use either MySQL or Microsoft SQL Server, odds are you're at least curious about trying out the competing product. Most of the time, SQL Server users are the ones interested in moving to MySQL to take advantage of a free, open source system -- but the reverse does happen. In this tip, I will examine some things you need to keep in mind when moving data between those two databases.
I assume you are not planning to share things like stored procedures or functions between the two databases because they are not cross compatible; you're just planning to share or convert data. How to deal with stored procedures or functions will be an upcoming feature on SearchSQLServer.com.
Data typing issues
The first and foremost, when you're moving between MySQL and SQL Server, consider how each program's data typing restrictions will affect what you're doing. One little gotcha is that MySQL and SQL Server may have similarly named data types with, in fact, radically different capacities.
SQL Server's VARCHAR data type, for instance, can hold up to 4,000 characters, while MySQL's VARCHAR can only hold up to 255 characters. If you were going from MySQL to SQL Server, that wouldn't be an issue, but if you were going in the other direction, you'd need to make a MySQL TEXT column to hold a SQL Server VARCHAR column. The folks at MySQL have a
Keep in mind VARCHAR and other character-based fields must be used in terms of characters -- not bytes -- due to Unicode conversion issues.
Another issue that parallels data typing is data normalization -- whether the data you're converting is already consistent or not. If you've followed strong data typing standards, this isn't a problem: A date field will convert to a date field, an integer field will convert to an integer field, and so on.
For instance, if you find that date and time values are being stored as freeform strings, stop and fix that problem first. The data present may already be polluted, and the last thing you want is to get all the way through the conversion only to discover you've copied data that wasn't worth copying in the first place.
Also, whenever you're correcting a problem like this, work on copies, never originals. You'll always benefit from having an untouched original copy to refer to in case something else goes wrong.
A plethora of tools are available for the actual data migration, depending on which way you're migrating. The best plan is to use the tools you are most comfortable using. For instance, if you have SQL Server experience, you'd be better off using SQL Server's own Data Transformation Services (DTS). As long as there's an ODBC driver available for a particular data source (yes, MySQL has one), you can shuttle data between any two sources easily, on demand or on a schedule. Its wizard-driven interface makes a great deal of the work relatively painless.
Another tool is MSSQL2MySQL, a Visual Basic script for converting from SQL Server or Access databases to MySQL. It's a command-line script, but there are a number of graphic interfaces available for it. MSSQL2MySWL also has a few drawbacks. For example, it doesn't provide any visual feedback during the conversion process. So, you may not want to use it for big databases that require a lot of processing.
For those on the MySQL side converting from SQL Server (who don't have much control over SQL Server but can access it an ODBC data source), you can use Webyog's SQLyog tool to do the conversion. It's functionally similar to SQL Server DTS, so former SQL Server users can probably wrap their minds around it without too much difficulty. Get a free trial edition. It may be just the thing you need to do the conversion alone.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
More information from SearchSQLServer.com
- Tip: MySQL vs. SQL Server
- Column: SQL Server DBMS' growing popularity is no coincidence
- Topic: Get more best practices on SQL Server integration and interoperability
This was first published in June 2006