同时支持 Oracle 和 MySQL:它们的 SQL 语法有多相似?
我们在一个项目中使用 Oracle,并且还希望支持 MySQL。他们的 SQL 方言有多接近?
是否有可能对两者使用相同的 SQL 源而不需要太多的体操?
详细信息:
- 我们使用 iBatis,它是一个持久性管理器,可以将 SQL 语句干净地隔离到资源文件中。但我们在 SQL 级别工作,这有其优点(和缺点)。
- 我们不想转向像 Hibernate 这样的对象关系映射器,它可以完全保护我们免受方言差异的影响。
- 我们努力保留 Oracle SQL 的通用子集。
- 没有 PL/SQL。
- 我们不使用存储过程或触发器(无论如何)。
- 我们使用检查约束、唯一约束和外键约束。
- 我们使用 ON DELETE CASCADE。
- 我们使用事务(在 iBatis API 级别完成)。
- 我们在查询中调用一些 Oracle 时间戳函数。
- 我们将使用 InnoDB 存储引擎和 MySQL(它支持事务和约束)。
那么你的想法是什么?我们是否需要维护两套不同的 iBatis SQL 资源文件,一套对应一种方言,或者是否可以有一组同时支持 MySQL 和 Oracle 的 SQL?
最终更新:感谢您的所有回答,特别是对 Troels Arvin 关于差异的页面的指出。确实令人遗憾的是,该标准并没有更加标准。对于我们来说,问题在于 MySQL 自动增量与 Oracle 序列、MySQL LIMIT 与 Oracle Rowumber(),或许还有一两个奇怪的函数。大多数其他内容都应该很容易传输,对一些编辑进行模数以确保我们使用 SQL-92,正如 @mjv 指出的那样。更大的问题是,某些查询可能需要在每个 DBMS 中进行不同的手动优化。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
预计路上会有一些小颠簸,但总体来说应该相对容易。
从您当前使用的功能列表中,应该只有一些句法或语义差异,通常很容易修复或解释。事实上,您不使用 PL/SQL 和/或存储过程是一个优点。一个好的经验法则是尝试并坚持使用大多数 DBMS 支持的 SQL-92,特别是 Oracle 和 MySQL。 (请注意,这不是当前的 SQL 标准,即 SQL-2008)。
一些差异:
刚刚发现似乎是 <关于 SQL 实现之间差异的好资源。
阅读其他人的回复,是的,DDL,可能是个问题。我不这么认为,可能是因为许多应用程序不需要 DDL,您只需要立即设置数据模式等,然后只需使用 SQL 来查询、添加或更新数据。
Expect a few minor bumps on the road, but on whole should be relatively easy.
From the list of features you currently use, there should only be a few synctactic or semantic differences, in general easy to fix or account for. The fact that you do not use PL/SQL and/or Stored Procedures is a plus. A good rule of thumb is to try and stick to SQL-92 which most DBMSes support, in particular both Oracle and MySQL. (Note this is not the current SQL standard which is SQL-2008).
A few of the differences:
Just found what seems to be a good resource about differences between SQL implementations.
Reading the responses from others, yeah, DDL, could be a problem. I discounted that probably because many applications do not require DDL, you just need to set the data schema etc. at once, and then just use SQL for querying, adding or updating the data.
我认为,使用 MySQL 和 Oracle 维护一组 SQL 资源文件有几个缺点,比如在向后兼容性和解决特定问题之间陷入困境。最好为每个 SQL 引擎都有一个 sql,从而最大限度地发挥每个 SQL 引擎的功能。
在宣传册中看起来相同的功能可能会以非常不同的方式实现。
请参阅这些示例
限制结果集
MYSQL
ORACLE
限制 - 带偏移量
MYSQL
ORACLE
您可以检查此 不同SQL实现的比较
I believe that maintaining a single set of SQL resource files with MySQL and Oracle, has several disadvantages as being caught between backward compatibility and solve a particular problem. it is best to have a sql for each SQL engine and thus maximize the capabilities of each.
Features that look identical in a brochure may be implemented very differently.
see these examples
Limiting result sets
MYSQL
ORACLE
Limit—with offset
MYSQL
ORACLE
You can check this Comparison of different SQL implementations
除了其他人提到的内容之外,oracle 和 mysql 处理外连接的方式也完全不同。实际上,Oracle 提供了 mySql 无法处理的语法,但 Oracle 会处理标准语法。
仅限 Oracle:
mySql 和 Oracle:
因此您可能必须转换一些外连接。
In addition to the stuff others have mentioned, oracle and mysql handle outer joins quite differently. Actually, Oracle offers a syntax that mySql won't cope with, but Oracle will cope with the standard syntax.
Oracle only:
mySql and Oracle:
So you may have to convert some outer joins.
您肯定无法保持 DDL 不变。就 DML 而言,有许多相似之处(每个数据库都支持 ANSI SQL 标准的核心子集),但也存在一些差异。
首先,MySQL 使用自动增量值,而 Oracle 使用序列。可以解决这个问题(Oracle 端的序列+触发器来模拟自动增量),但它就在那里。内置函数有很大不同。
基本上,根据您的具体用途,可能会或可能不会为两者保留一组语句。顺便说一句,即使使用 Hibernate 方言,也并不总是能够拥有相同的查询集 - HQL 很棒,但并不总是足够。
You definitely won't be able to keep your DDL the same. As far as DML goes, there are many similarities (there's a core subset of ANSI SQL standard supported by every database) but there are some differences as well.
To start, MySQL uses auto increment values and Oracle uses sequences. It's possible to work around this (sequence + trigger on Oracle side to simulate auto increment), but it's there. Built-in functions are quite different.
Basically, depending on what exactly you intend to use it may or may not be possible to keep one set of statements for both. Incidentally, even with Hibernate dialects it's not always possible to have the same set of queries - HQL is great but not always enough.
Oracle 将空字符串视为空值。 MySQL 将空字符串视为空字符串,将空字符串视为空字符串。
Oracle treats empty strings as nulls. MySQL treats empty strings as empty strings and null strings as null strings.