数据库引擎在SQL级别具有多少兼容性？

Question

假设我想要一个可以在后端轻松切换数据库的应用程序 我主要将SQL Server视为主要的后端，但可以灵活地使用另一个数据库引擎。 Firebird和PostGreSQL似乎（从我简短的维基百科游览中）与SQL Server最常见（加上它们是免费的）。

对于Firebird，PostGreSQL和MS SQL Server，数据库设置，访问，查询等有多相似？

Answer 1

不幸的是，SQL在提供商之间差异很大。除了最简单的SQL之外，几乎不可能在大量的RDBMS上运行 - 然后你就会进入最低的公分区域。最好使用抽象层来处理至少与数据库的连接（包括访问，发送查询），以及用于处理SQL本身或每个提供者SQL的ORM。

如果你想看看它们是如何变化的 - 好的例子是自动递增id并获得最后插入记录的ID。

Answer 2

我参与了一个项目，它绝对需要支持许多数据库，包括至少包括Access，SQL Server和Oracle。

所以我知道可以做到。大多数情况下，DML（SELECT，UPDATE，INSERT ...）是相同的，当然我们没有遇到很大的问题，使它在所有数据库中工作 - 只是偶尔的烦恼。 MySQL当时是个例外，因为它根本没有足够的能力。

我们发现DDL中存在大多数差异，但是使用正确的架构（我们有），解决这个问题并不困难。

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

它确实让事情变得更容易，因为我们避免在ID字段中使用自动增量，更难以考虑唯一键 - 但从长远来看更好。

Answer 3

嗯，CRUD的东西应该在任何地方都是一样的，但如果你构建任何复杂的东西，你可能会想要使用触发器和存储过程，这就是兼容性变低的地方。编写与DBMS无关的应用程序通常意味着将大多数业务逻辑移到数据库之外，因此在这种情况下，拥有3层应用程序是恕我直言。

或者，您可以使用一些像抽象层一样工作的包装器库，但我还没有看到一个能够在一系列DBMS-es上正确完成工作的包装器库。当然，这也取决于您使用的编程语言。

Answer 4

正如其他答案所指出的，一旦超出基本的SELECT / INSERT内容（有时甚至是那里），DBMS会有很大差异。

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

特别是，看看流行的ORM（Hibernate，nHibernate等）可能会有所收获。它们通常提供DB独立性作为一种副作用。至少Hibernate还有一种特殊的查询语言，它将自动转换为您正在使用的DBMS的SQL。