Java 编程 - SQL 语句应该存储在哪里？

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

7年前关闭。



Improve this question




符合 JDBC 的应用程序应该在哪里存储它的 SQL 语句，为什么？

到目前为止，我设法确定了这些选项:

硬编码在业务对象中

嵌入SQLJ条款

封装在单独的类中，例如
Data Access Objects

元数据驱动(解耦对象
来自数据模式的模式 -
描述它们之间的映射
元数据)

外部文件(例如属性或
资源文件)

存储过程

每个人的“优点”和“缺点”是什么？

SQL 代码应该被视为“代码”还是“元数据”？

存储过程应该仅用于性能优化还是数据库结构的合法抽象？

性能是决定的关键因素吗？怎么样 vendor lock-in ?

哪个更好——松耦合或紧耦合，为什么？

编辑:谢谢大家的回答——这里是一个总结:

元数据驱动，即对象关系映射 (ORM)

优点:

很抽象——DB服务器可以
无需更改即可切换
型号

广泛传播 - 几乎是标准

减少所需的 SQL 量

可以在资源文件中存储 SQL

性能(通常)可以接受

元数据驱动方法

(数据库)供应商独立

缺点:

隐藏 SQL 和真正的开发人员
意向

难以审查/更改的 SQL
通过 DBA

奇数可能仍需要 SQL
案例

可以强制使用专有的
查询语言，例如HQL

不利于优化
(抽象)

可能缺乏参照完整性

缺乏SQL知识的替代品
或不小心在 DB 中编写代码

从不匹配 native 数据库
性能(即使接近)

模型代码很紧加上
数据库模型

硬编码/封装在 DAO 层

优点:

SQL 保存在对象中
访问数据(封装)

SQL 易于编写(速度为
发展)

SQL 在以下情况下很容易跟踪
需要更改

简单的解决方案(不乱
建筑)

缺点:

DBA 无法审查/更改 SQL

SQL 很可能成为 DB-specific

SQL 可能变得难以维护

存储过程

优点:

SQL 保存在数据库中(接近
数据)

SQL 被解析、编译和优化
由 DBMS

SQL 便于 DBA 查看/更改

减少网络流量

增加安全性

缺点:

SQL 绑定(bind)到数据库(供应商
锁定)

SQL 代码更难维护

外部文件(例如属性或资源文件)

优点

无需更改 SQL 即可
重建应用程序

将 SQL 逻辑与
应用业务逻辑

所有 SQL 的中央存储库
报表 – 更易于维护

更容易理解

缺点:

SQL 代码可能变得不可维护

更难检查 SQL 代码
(语法)错误

嵌入在 SQLJ 子句中

优点:

更好的语法检查

缺点:

与 Java 的关系过于紧密

性能低于 JDBC

缺少动态查询

不太受欢迎

Answer 1

通常，应用程序在大小和/或可重用性方面增长得越多，就越需要外部化/抽象化 SQL 语句。

硬编码(作为静态最终常量)是第一步。
存储在一个文件(properties/xml 文件)中是下一步。
元数据驱动(如 Hibernate/JPA 之类的 ORM 所做的那样)是最后一步。

硬编码的缺点是您的代码可能会成为特定于数据库的代码，并且您需要在每次更改时重写/重建/重新分发。优点是您可以在 1 个地方使用它。

存储在文件中的缺点是当应用程序增长时它可能变得不可维护。优点是您不需要重写/重建应用程序，除非您需要添加额外的 DAO 方法。

元数据驱动的缺点是您的模型代码与数据库模型耦合非常紧密。对于数据库模型中的每个更改，您都需要重写/重建/重新分发代码。优点是它非常抽象，您可以轻松地从数据库服务器切换而无需更改模型(但现在问问自己:公司多久会从数据库服务器切换一次？可能至少每 3 年一次，是吗？是吗？)。

我不会将存储过程称为“好的”解决方案。他们有一个完全不同的目的。尽管如此，您的代码将取决于所使用的数据库/配置。