Java编程-SQL语句应存储在哪里？[关闭]

兼容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
• 缺乏动态查询
• 不太受欢迎

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

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

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

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

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

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

我不知道这是否是最佳选择，但是根据我的经验，它们最终会在DAO层中进行硬编码（即字符串文字）。

我认为没有人会给您您想要的专业意见，因为这是一个很大的问题。因此，这里是我过去使用的东西，以及以后将使用的东西。

我曾经使用在DAL中硬编码的SQL。我认为这很好，直到DBA想要使用SQL。然后，您必须对其进行挖掘，格式化并将其发送到DBA。谁会嘲笑它，并取代一切。但是没有好的问号，或没有按错误的顺序问号，让您将其留在Java代码中。

我们还使用了ORM，尽管这对开发人员来说非常好，但我们的DBA讨厌它，因为没有SQL可供他们嘲笑。我们还使用了一个奇怪的ORM（第三方供应商定制的ORM），它习惯于杀死数据库。从那时起，我就一直在使用JPA，而且功能非常强大，但是使用它通过DBA进行的任何复杂操作都是艰巨的任务。

现在，我们使用存储过程（带有硬编码的调用语句）。现在，每个人都会抱怨的第一件事是您已绑定到数据库。你是。但是，您多久更改一次数据库？我知道一个事实，就是我们根本无法尝试它，依赖于它的其他代码数量加上重新训练DBA以及迁移数据的能力。这将是非常昂贵的操作。但是，如果在您的世界中需要一口气更换数据库，则可能需要SP。

展望未来，我想将存储过程与代码生成工具一起使用，以便从Oracle软件包中创建Java类。

编辑2013-01-31：几年后和DBA一起使用，现在我们使用Hibernate，仅在绝对需要时才使用SQL（数据库中存储的proc）。我认为这是最好的解决方案。数据库有99％的时间不需要担心SQL，而他们有1％的时间在他们已经习惯的地方。

通过使用ORM（例如休眠），希望您不必担心SQL语句。性能通常是可以接受的，并且您也可以获得供应商的独立性。

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

码。

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

存储过程允许重用，包括在其他存储过程内部。这意味着您可以一次访问数据库并让其执行支持的指令-最小的流量是理想的。ORM或sproc，到达数据库和返回数据库的时间是您无法弥补的。

ORM由于其抽象而不适合进行优化。IME，ORM还意味着缺乏参照完整性-使得数据库难以报告。节省下来的复杂性现在已经增加，能够以可行的方式获取数据。

性能是决定的关键因素吗？供应商锁定如何？

不，简单是。供应商锁定也发生在数据库中-SQL是相对标准化的，但是仍然有特定于供应商的处理方式。

担心Java世界中的供应商锁定很有趣。

我希望您没有为Oracle Enterprise支付$ 50000 pr的CPU，然后仅使用最小公分母来随时切换到Mysql。就像任何优秀的DBA都会告诉您的那样，不同的大名称数据库之间存在细微的差异，尤其是在锁定模型以及它们如何实现一致性方面。

因此，不要仅根据供应商不可知SQL的原则来决定如何实施SQL调用-这样做的真实原因（业务原因）。

存储过程中的SQL已由数据库系统优化，并针对速度进行了编译-这是它的自然本源。SQL由数据库系统理解，由数据库系统解析。如果可以，将SQL保留在数据库中；将其包装在存储过程或函数中，或者数据库系统提供的任何逻辑单元中，并使用您或任何其他人提到的任何一种工具对其进行简单调用。

为什么要在db外部存储数据库系统的SQL代码？通常是为了加快发展速度。为什么要使用ORM映射？-有人说ORM映射提供了不同数据库系统之间的兼容性；但是，在现实世界中，很少有应用程序在构建后就离开数据库平台，特别是当它开始使用复制等高级功能时，并且在极少数情况下确实发生了数据库系统被换出的情况，因此需要做一些工作。我相信，ORM的缺点之一通常可以替代SQL知识的缺乏或对数据库代码的缺乏的关注。而且，即使ORM接近本机数据库性能，它也永远无法与之匹敌。

我站在将SQL代码保留在数据库中，并通过您希望使用的任何API或接口对其进行简单调用的立场。通过将这些调用放在抽象类或OO接口（由方法表示）之后，还可以抽象出进行数据库调用的时间，因此，如果您交换了一种新型的数据源，它将对业务层无缝。

您要问的唯一一个肯定的问题是“是SQL代码还是元数据？” 它绝对是代码，因此应保留在某种源代码控制中，并具有一个可以轻松更新到最新版本并在出现问题时可以回滚的系统。

我已经看到了在应用程序中执行SQL的三种方法，每种方法各有利弊。没有最好的方法，但是最好的办法就是选择一种与您的应用程序兼容的应用并坚持下去。

• ORM-这减少了您需要编写的SQL数量，并为您处理了许多细节。您将需要执行一些自定义SQL。确保您有一个可以正常处理的ORM。
• 数据访问对象-将SQL保留在访问数据的对象中。这将封装您的数据库并使之成为数据库，因此您的应用程序的其余部分无需了解底层数据库结构，而只需了解这些对象的接口即可。
• 存储过程-这将您所有的SQL保留在数据库中，并使DBA可以轻松了解正在发生的事情。您所需要做的就是让您的代码调用存储的proc

我们碰巧使用了iBatis SQL映射器，它比像Hibernate这样的ORM更接近金属。在iBatis中，您将SQL语句放入资源文件（XML）中，该文件必须位于类路径中。

如果添加@ocdecio的ORM选项，则您的方法列表似乎很全面。我会说使用ORM以及使用SQL映射器和资源文件是两种最佳方法。我会避免使用SQLJ，因为SQLJ尚未被广泛使用，并且与Java的联系也太紧密了。还应远离存储过程，因为它们将您绑定到特定的数据库供应商（存储过程几乎不存在标准）。

像我们大多数人一样，我已经看到了整个过程，但是我们需要将SQL视为一流的语言。我什至看到存储在数据库中的SQL被拉低然后又执行回去。

我见过的最成功的系统采用存储过程，功能和视图。

存储的proc将SQL文本保留在DB中，并允许那些DEPLOYING和CUSTOMIZING（需要大量适当的设计来支持它）进行相对立即的更改。

出于相同的原因，所有投影都应通过视图和简单选择进行，所有投影逻辑都应包含在视图内。

我建议使用具有工厂布局的DAO。因此，您需要的示例对象是：

public class CoolBusinessObject
public class DAOFactory.java
public implementation CoolBusinessOjectDAO
public class CoolBusinessOjectDAOOracleImpl implements CoolBusinessOjectDAO

这种样式使数据交互分层，因此，如果您切换数据库或使用ORM技术，则只需更改一层代码。

这三个之间实际上并没有任何实质性的区别：

1. 硬编码在业务对象中
2. 嵌入在SQLJ中子句中
3. 封装在单独的类中，例如数据访问对象

我假设您将SQL代码以字符串形式直接嵌入到Java代码中。虽然1和3可能会直接使用JDBC（或诸如Apache DbUtils之类的工具），但2在堆栈中添加预处理器技术，从而在编译之前生成相关的JDBC代码。

因此，从本质上讲，如果这些解决方案涉及嵌入SQL，则最好使用以下任何一种技术：

• JPA Criteria API，将JPQL建模为Java中内部特定于域的语言
• jOOQ，将SQL建模为Java中内部特定于域的语言

与通过SQLJ或通过实际的字符串连接相比，可能还有其他工具可以帮助您以更加类型安全的方式将SQL嵌入Java中。

从我的经验来看，在DAO对象中硬编码sql语句是被广泛使用的方法，但是，我认为它应该是最不受欢迎的方法。最佳实践应该是将sql语句存储在属性文件中。并通过属性文件（例如java.util.Properties）的接口获取DAO对象中的语句。sql语句可以通过“ Prepared Statement”方法插入“？”以传递参数。

这种方法有助于将sql逻辑与应用程序业务逻辑分离。这样就可以为所有sql语句提供一个中央存储库，从而使修改变得更加容易，从而消除了在应用程序逻辑中搜索数据库语句的需求。

我的最终陷入了资源束。我知道这是不正常的，但对我和任何“我以外的人”来说，维护起来最简单。这是直接且合乎逻辑的。

我真的很想知道是否有人也使用我的方法。

作为一个rexem所写，SQL语句是代码-应该将它们视为代码，而不是外部化（除非您有充分的理由），而应与处理该语句的SQL数据的代码放置在一起。如今的ORM / iBatis框架为日常JDBC开发提供了许多简化方法。

您将在此问题中找到问题的一些答案：）如何存储SQL语句的问题取决于您的应用程序。你有什么需要 高安全性，编写代码或维护的便利性，跨平台或供应商锁定？下一个问题，您需要纯SQL还是ORM框架会很好？

* Hardcoded in business objects
* Encapsulate in separate classes e.g. Data Access Objects

最简单的解决方案（P），难以维护（C）

* Embedded in SQLJ clauses

更好的语法检查（P），缺少动态查询（C），性能比JDBC（C）低，没有那么流行（C）

* Metadata driven (decouple the object schema from the data schema - describe the mappings between them in metadata)

在特定情况下，您应该执行（C）或使用ORM（P）;）

* External files (e.g. Properties or Resource files)

易于维护（P），但更难检查错误（C）

* Stored Procedures

高安全性（P），难以维护供应商锁定问题的代码（C）