数据库引擎在SQL级别有多大的兼容性?

我在一个项目中工作,在这个项目中,支持许多数据库是绝对必要的,至少包括Access、SQL Server和Oracle。

所以我知道这是可以做到的。大多数情况下,DML(select、update、insert…)都是相同的,当然,我们在所有的数据库中都没有遇到巨大的问题——只是偶尔的麻烦。MySQL在当时是个例外,因为它根本没有足够的能力。

我们在DDL中发现了大部分的差异,但是有了正确的体系结构(我们拥有的),解决这个问题并不困难。

唯一导致我们出现问题的是生成唯一的ID-autoincrement是非标准的。在大约40个表的数据库中,只有几个地方需要唯一的ID(良好的DB设计)。最后,我们在代码中生成唯一的ID,并处理任何冲突(事务中的所有内容)。

它确实使事情变得更简单,因为我们避免了对ID字段使用autoincrement,更难想到唯一的键——但从长远来看会更好。

不幸的是,不同的提供程序之间的SQL差异很大。除了最普通的SQL以外,几乎不可能在许多RDBMS上运行所有的SQL,然后您就进入了最小公分母的领域。最好使用抽象层来处理与数据库的连接(包括访问、发送查询),或者使用ORM来处理SQL本身,或者使用每个提供程序的SQL。

如果您想了解它们是如何变化的-很好的例子是自动递增ID并获取最后插入的记录的ID。

好吧,CRUD的东西在任何地方都应该是相同的,但是如果构建了复杂的东西,那么您可能需要使用触发器和存储过程,这使得兼容性变得很低。编写DBMS不可知的应用程序通常意味着将大部分业务逻辑移出数据库,因此在这种情况下,三层应用程序是必不可少的。

或者,您可以使用一些类似于抽象层的包装库,但是我还没有看到一个能够在DBMS范围内正确地完成工作的库。当然,这也取决于您使用的编程语言。

正如其他答案所指出的,一旦您超越了基本的选择/插入内容(有时甚至超越了基本的选择/插入内容),DBMS就会发生巨大的变化。

我们还必须在几个DBMS之间保持兼容性。在我看来,最好的方法通常是使用某种兼容层。我们有一个内部的数据库抽象库,但是有几个工具可用。

特别是,看流行的虫虫(冬眠、无纤维虫等)可能会很划算。它们通常提供数据库独立性作为一种副作用。至少Hibernate还有一种特殊的查询语言,它将自动转换为您使用的DBMS的SQL。