We use Oracle on a project and would like to also support MySQL. How close are their SQL dialects?
Is it perhaps even possible to use the same SQL source for both without too many gymnastics?
Details:
- We re using iBatis, a persistence manager that cleanly segregates the SQL statements into resource files. But we work at the SQL level, which has its advantages (and disadvantages).
- We d prefer not to move to an object-relational mapper like Hibernate, which would fully shield us from dialect differences.
- We ve tried hard to keep to a generic subset of Oracle SQL.
- There s no PL/SQL.
- We don t use stored procedures or triggers (yet, anyway).
- We use check constraints, unique constraints, and foreign key constraints.
- We use ON DELETE CASCADEs.
- We use transactions (done at the iBatis API level).
- We call a few Oracle timestamp functions in the queries.
- We would use the InnoDB storage engine with MySQL (it supports transactions and constraints).
So what are your thoughts? Would we need to maintain two different sets of iBatis SQL resource files, one for each dialect, or is it possible to have a single set of SQL supporting both MySQL and Oracle?
Final Update: Thanks for all the answers, and especially the pointers to Troels Arvin s page on differences. It s really regrettable that the standard isn t more, well, standard. For us the issues turn out to be the MySQL auto-increment vs. the Oracle sequence, the MySQL LIMIT vs. the Oracle Rowumber(), and perhaps the odd function or two. Most everything else ought to transfer pretty easily, modulo a few edits to make sure we re using SQL-92 as @mjv points out. The larger issue is that some queries may need to be hand-optimized differently in each DBMS.