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

Question

兼容JDBC的应用程序应在哪里存储其SQL语句，为什么？

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

• 硬编码在业务对象中
• 嵌入在SQLJ子句中
• 封装在单独的类中，例如 数据访问对象
• 驱动元数据（将对象模式与数据模式分离-在元数据中描述它们之间的映射）
• 外部文件（例如属性或资源文件）
• 存储过程

各自的“优点”和“缺点”是什么？

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

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

性能是决定的关键因素吗？什么厂商锁定？

更好的是松耦合还是紧耦合，为什么？

编辑：谢谢大家的答案–以下是摘要：

元数据驱动，即对象关系映射（ORM）

优点：

• 非常抽象-无需更改模型即可切换DB服务器
• 广泛传播-实际上是一个标准
• 减少所需的SQL数量
• 可以将SQL存储在资源文件中
• 性能（通常）是可以接受的
• 元数据驱动的方法
• （数据库）供应商独立性

缺点：

• 隐藏SQL和真正的开发人员意图
• DBA难以审核/更改SQL
• 奇数情况下可能仍需要SQL
• 可以强制使用专有查询语言，例如HQL
• 不适合进行优化（抽象）
• 可能缺乏参照完整性
• 缺乏SQL知识或对数据库中的代码缺乏关注的替代品
• 永远无法达到本机数据库性能（即使接近）
• 模型代码与数据库模型紧密结合

硬编码/封装在DAO层中

优点：

• SQL保留在访问数据的对象（封装）中
• SQL易于编写（开发速度）
• 需要更改时，SQL很容易跟踪
• 简单的解决方案（没有凌乱的架构）

缺点：

• DBA无法检查/更改SQL
• SQL可能成为特定于DB的
• SQL可能变得难以维护

存储过程

优点：

• SQL保存在数据库中（靠近数据）
• SQL由DBMS解析，编译和优化
• SQL对于DBA来说很容易查看/更改
• 减少网络流量
• 增强安全性

缺点：

• SQL与数据库绑定（供应商锁定）
• SQL代码更难维护

外部文件（例如属性或资源文件）

优点

• 可以更改SQL，而无需重建应用程序
• 将SQL逻辑与应用程序业务逻辑解耦
• 所有SQL语句的中央存储库–易于维护
• 更容易理解

缺点：

• SQL代码可能变得难以维护
• 难以检查SQL代码中的（语法）错误

嵌入在SQLJ子句中

优点：

• 更好的语法检查

缺点：

• 与Java的联系太紧密
• 性能低于JDBC
• 缺乏动态查询
• 不太受欢迎

Answer 1

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

硬编码（作为静态最终常量）是第一步。下一步是存储在文件（properties / xml文件）中。最后一步是驱动元数据（由像Hibernate /
JPA这样的ORM完成）。

硬编码的缺点是您的代码可能变得特定于数据库，并且每次更改都需要重写/重建/重新分发。好处是您可以将它放在1个地方。

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

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

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