Migrating From Oracle To MySQL

Question

Currently I am migrating databases from Oracle to MySQL. I mainly use Java to send queries to the database using JDBC. In the process of migrating, I need to change a lot of my queries in the Java code (the queries are hard-coded) as they will not work in MySQL.

I want to be able to recode my queries in such a way that I can easily switch between the databases if problems arise; I am changing all my queries to standard SQL but there are areas where this is not possible. I am thinking of having two versions of the queries, one for Oracle and one for MySQL so I can switch between both (I will have two versions temporarily just to see if MySQL can cope with our needs). However this seems like a terrible idea - does any one have any advice on a better way they would do this?

Answer 1

You have a bunch of options.

Firstly, many people now use Object-Relational Mapping (ORM) tools to connect applications to SQL databases. These come in a variety of different flavours - Hibernate is popular - and allow you switch between databases at very little cost. However, they do have a fairly steep learning curve. Inexperienced developers often struggle with performance problems in ORM applications.

If you stick with "traditional" JDBC, I suggest you take the body of the SQL out of the Java code, and treat it like a resource. As Henry suggests, you could use property files, and use parameter placeholders (ideally named placeholders, using the Spring template ). While this does spread the code for a given piece of functionality into two files, it makes it easy to quickly refine the SQL and test new versions.

Answer 2

One possibility is to store the queries in a properties file. You would have one for Oracle and one for MySql.

Answer 3

I must add - ORM is good advice and will work... when you are starting with a fresh application and you can design your application to work on a domain model.

In this case however there is an existing application that invokes a great number of SQL queries. ORM based queries (HQL, JPQL) translate to SQL just fine; SQL does not by definition translate to the ORM layer however, major changes will be needed to make it a more object oriented approach to the data.

The problem will still persist even when you do manage to work in an ORM layer. There is already a major difference between MySQL and Oracle in how primary key generation works for example; MySQL uses auto-numbering where Oracle uses a sequence. Likely you already have an existing datamodel that you need to reverse engineer into the ORM layer code; it isn't going to be cross-database code.