java - Hibernate 和 SQL 可移植性

Question

我是持久性的新手，我正在阅读“Pro JPA 2”一书。我读到Java和JDBC包的问题是

1. SQL 不可移植
2. Java 代码和 SQL 之间的紧密耦合

JDBC 具有讽刺意味的是，尽管编程接口是可移植的，但 SQL 语言却不是。尽管进行了多次标准化尝试，但编写在两个主要数据库平台上不变运行的复杂 SQL 仍然很少见。即使在 SQL 方言相似的情况下，每个数据库的性能也会根据查询的结构而有所不同，在大多数情况下都需要针对供应商进行调整。

我的问题是：

1. 与 SQL 可移植性相关的问题是否仍然如此关键？
2. 据我了解，Hibernate、TopLink 和其他框架也必须从它们的元数据（注释）创建 SQL 查询。他们如何安排与 SQL 可移植性相关的问题？
3. Java 和 JDBC 紧耦合意味着开发人员必须编写 SQL 查询。我理解正确吗？

提前感谢您的回复）

Answer 1

1. 是的，问题在于 SQL 和代码之间的紧密耦合，这对项目非常关键，因为如果我们需要在没有 ORM 的情况下从一个数据库迁移到另一个数据库，我们需要更改应用程序中的所有查询。

2. Hibernate、TopLink 和其他 ORM 解决方案将您的 java 代码转换为 SQL 查询并将它们发送到数据库，但它们更加标准且经过良好测试，因此我们可以依赖 ORM 工具，而不是直接处理查询，它将我们的代码转换为查询和将我们从复杂性中抽象出来。所以最好使用 ORM 工具而不是直接编写查询。

3. 是的，Java 和 JDBC 紧耦合意味着开发人员必须直接编写不可移植的 SQL 查询，并且如果数据库层发生变化，您需要更改所有查询。相反，如果您使用 ORM 解决方案，您可以直接迁移到 ORM 支持的任何数据库，只需更改一些 XML 或配置文件。

Answer 2

如果您需要切换到不同的数据库，SQL 可移植性将是一个问题。

很容易认为你永远不会转换，但这可能代价高昂。我一直在假设数据库始终是供应商 x 的项目中，但后来也需要供应商 y 数据库。要使应用程序与这两个数据库一起工作，需要进行大量痛苦、乏味的返工。

我建议您始终使用标准 SQL 和/或使用仅编写标准 SQL 的 ORM 工具。

我的 ORM，sormula，总是创建标准 SQL。如果您使用 sormula 开发了一个应用程序，那么切换数据库所需要做的就是更改 jdbc jar。