Java编程SQL语句应该存储在哪里？
兼容JDBC的应用程序应该将其SQL语句存储在哪里？为什么
到目前为止，我成功地确定了以下选项：
- 业务对象中的硬编码
- 嵌入SQLJ子句中
- 封装在单独的类中。 Data Access Objects
- 元数据驱动（解耦对象） 数据模式中的模式- 请在中描述它们之间的映射 元数据）
- 外部文件（例如属性或 资源文件）
- 存储过程
每种方法的“优点”和“缺点”是什么
SQL代码应该被视为“代码”还是“元数据”
存储过程应该只用于性能优化，还是作为数据库结构的合法抽象
绩效是决定的关键因素吗？那vendor lock-in呢
什么更好？松耦合还是紧耦合？为什么
编辑：感谢大家的回答——这里是一个总结：
元数据驱动，即对象关系映射（ORM）
优点：
- 非常抽象-数据库服务器可以 无需更改即可切换 模型
- 广泛传播——实际上是一种标准
- 减少所需的SQL数量
- 可以在资源文件中存储SQL
- 性能（通常）可以接受
- 元数据驱动的方法
- （数据库）供应商独立性
缺点：
- 隐藏SQL和真正的开发人员 意图
- SQL难以审核/更改 由DBA提供
- 奇怪的情况下，可能仍然需要SQL 案例
- 可以强制使用专有的 查询语言，例如HQL
- 不适合优化 （抽象）
- 可能缺乏引用完整性
- 替代缺乏SQL知识 或者对数据库中的代码缺乏关注
- 从不匹配本机数据库 性能（即使接近）
- 模型代码与 数据库模型
硬编码/封装在DAO层中
优点：
- SQL保存在 访问数据（封装）
- SQL易于编写（编程速度） 发展）
- 当 需要进行更改
- 简单的解决方案（无混乱） （建筑）
缺点：
- 数据库管理员不能审核/更改SQL
- SQL可能会变得特定于数据库
- SQL可能变得很难维护
存储过程
优点：
- SQL保存在数据库中（接近 （数据）
- SQL被解析、编译和优化 由数据库管理系统
- DBA很容易查看/更改SQL
- 减少网络流量
- 加强安全
缺点：
- SQL与数据库（供应商）绑定 （锁定）
- SQL代码更难维护
外部文件（例如属性或资源文件）
专业人士
- SQL可以在不需要修改的情况下进行更改 重建应用程序
- 将SQL逻辑与 应用程序业务逻辑
- 所有SQL数据库的中央存储库 报表–易于维护
- 更容易理解
缺点：
- SQL代码可能会变得不可维护
- 更难检查SQL代码 （语法）错误
嵌入SQLJ子句中
优点：
- 更好的语法检查
缺点：
- 与Java的联系过于紧密
- 性能低于JDBC
- 缺乏动态查询
- 不太受欢迎
# 1 楼答案
通常，应用程序在规模和/或可重用性方面增长得越多，就越需要将SQL语句外部化/抽象化
硬编码（作为静态最终常数）是第一步。 下一步是存储在文件（properties/xml文件）中。 元数据驱动（由类似Hibernate/JPA的ORM完成）是最后一步
硬编码的缺点是，代码可能会变得特定于数据库，并且每次更改都需要重写/重建/重新发布。优点是你把它放在了一个地方
存储在文件中的缺点是，当应用程序增长时，它可能会变得不可维护。优点是不需要重写/重建应用程序，除非需要添加额外的DAO方法
元数据驱动的缺点是模型代码与数据库模型紧密耦合。对于数据库模型中的每一个更改，您都需要重写/重建/重新分发代码。优点是它非常抽象，您可以轻松地从DB服务器切换，而无需更改您的模型（但现在问问自己：一家公司会多久从DB服务器切换一次？可能至少每3年才切换一次，不是吗？）
我不认为存储过程是解决这个问题的“好”解决方案。他们有完全不同的目的。尽管如此，您的代码将取决于所使用的DB/配置
# 2 楼答案
通过使用ORM（比如hibernate），你很可能会担心没有SQL语句。性能通常是可以接受的，而且您还可以获得供应商独立性
# 3 楼答案
java世界中对供应商锁定的恐惧很有趣
我希望你没有为甲骨文企业支付50000美元的公关CPU，然后只使用最小公分母，以便随时切换到Mysql。任何一位优秀的DBA都会告诉您，不同的大型数据库之间存在细微的差异，尤其是在锁定模型以及它们如何实现一致性方面
因此，不要仅仅基于与供应商无关的SQL原则来决定如何实现SQL调用——这样做有一个真正的（业务）原因