java - 封装 SQL 平台差异的策略？

Question

我在这里致力于加速一些缓慢的操作，一个案例是表中的父子关系树。目前系统运行在SQLServer上，经过一番研究发现使用公用表表达式可以将多个查询压缩为一个。

到目前为止还不错，但是语法是 SQLServer 特有的，用(例如)Oracle 做同样的事情需要完全不同的语法。

可以做些什么来构造系统以允许将来适应其他 RDBMS？我主要关心的是:

• SQL 语句散布在代码中，一个 RDBMS 中的 一个 语句可能需要另一个 RDBMS 中的多个语句，因此甚至程序逻辑也可能需要更改。
• 即使是可以很好地封装在一个 RDBMS 中的东西(我使用存储函数来隐藏数据库中的一些复杂性)在不同的数据库中也有细微的差别，或者根本不可用。

到目前为止，我觉得除了最简单的 SQL 语句之外的所有内容似乎总是需要供应商特定的扩展，这使得不可能将差异整齐地隐藏在几个类/存储的 SQL 中(肯定可以 使用一个已经内置了大部分抽象的框架。但这也排除了数据库的许多更有用的功能。

可以使用哪些策略至少减轻供应商差异带来的痛苦？我知道这是一个非常广泛的问题，没有包治百病的答案。但我希望有一些指示和模式来减轻数据库对应用程序的影响。

编辑:实现语言是 Java，仅使用 ORM(例如 Hibernate)并不是我想要的(或多或少需要重写约 50% 的代码库)。

EDIT2:我主要寻找以尽可能普遍兼容的方式将细节推送到数据库中的可能性，理想情况下我希望 java 部分使用的 SQL 对于所有平台都是相同的(或者由于语法差异，只需要非常轻微的更改)。对于我给出的 CTE 示例，我目前将其推送到存储函数中，希望在需要移植时也可以在函数中重现该功能。

EDIT3:目前我没有迫切需要支持其他 RDBM。如果它只适用于 SQLServer，没有人会责怪我。但在可能的情况下，我希望避免将 Java 代码过多地绑定(bind)到特定的数据库供应商。

EDIT4:一些背景 - 当前的工作是向系统添加功能 - 它不是设计或计划的功能。业务人员一点一点地提出要求，很难提前计划。虽然每个需求本身并不是很难解决，但恐怕我们会积累一大堆标记的东西，如果不仔细检查每个查询就无法移植这些东西。由于 SQLServer 本身也在每个主要新版本中引入了各种不兼容问题，我担心即使切换到更新的 SQLServer 也可能成为 future 的主要障碍(过去我们从 2005 年到 2008 年进行了一次这样的升级 - 那一次去了我正在维护的东西很顺利，但它已经给我们的一个供应商带来了很多问题)。

Answer 1

1. 远离 ORM。它们在项目中确实有它们的用途，但如果您只想要数据库独立性，那么当您只需要一把锤子和一些钉子时，这就像购买一个通用工厂工厂。

2. 将您的数据访问层隔离在一组接口(interface)之后。你的代码库中没有任何东西应该依赖于数据库，而是这些接口(interface)的实现。因此，这些实现之外的任何类都不应访问类路径中带有“jdbc”、“jpa”或“hibernate”的任何内容。您可能会考虑使用 JDepend 或 DependencyFinder 编写实际测试。

3. 让您当前的数据库访问实现这些接口(interface)。

4. 拥有针对实际数据库运行并准备针对一组不同数据库运行的自动化测试。

5. 当您必须支持第二个数据库时，请修改您的测试以针对这两个数据库运行。使接口(interface)实现成为原始实现的副本，然后修复失败的测试。

6. 现在查看您的两个实现，找到值得提取的内容并相应地重构您的代码。

如果您尝试将第 6 步进一步移到链中，您将遇到 YAGNI 和 WrongAbstractionException 的不良情况。

如果您决定使用任何类型的 ORM 或某些其他数据库访问技术，则适用相同的规则。