郑州尚学堂:在 Java 中如何更高效地存储和管理 SQL 语句?

  

  如果使用的是普通的、没有任何外部类库的 Java JDBC,那么就必须得自己去管理 SQL 语句。很不幸的是,Java String 并不支持多行结构,所以开发者必须使用许多引号+连接符来拼接语句,这会使得 SQL 语句非常难于阅读和管理。同时,这也使得维护和测试(尝试从 Java 代码中 Copy 一条 SQL 语句到 SQL 客户端运行)更加困难。如果能保证整条 SQL 语句完好无缺,又避免了 Java 的干扰,就更好了。这里有个快速解决方案,把 SQL 查询语句存储在 XML 的 CDATA 里面:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<sqlMap>
    <sqls>
        <entry>
            <key>getUser</key>
            <value><![CDATA[
SELECT *
FROM USERS
WHERE ID = ?
            ]]></value>
        </entry>
        <entry>
            <key>getSpecialCodeByUserId</key>
            <value><![CDATA[
SELECT u.EMAIL, p.ID as PROFILEID, p.SPECIALCODE, a.MANAGERID
FROM USERS u
  LEFT JOIN PROFILE p ON p.USERID = u.ID
  LEFT JOIN ACCOUNT a ON a.PROFILEID = p.ID
WHERE u.ID = ?  ]]></value>
        </entry>  </sqls>
</sqlMap>

  如果现在再去读 SQL 语句,开发者可以利用内建的 JAXB。

import javax.xml.bind.annotation.XmlRootElement;
import java.util.HashMap;
import java.util.Map;
@XmlRootElement
public class SqlMap {
    Map<String, String> sqls = new HashMap<>();
    public Map<String, String> getSqls() {
        return sqls;
    }
    public void setSqls(Map<String, String> sqls) {
        this.sqls = sqls;
    }
    public String getSql(String name) {
        return sqls.get(name);
    }
    public static SqlMap load(String name) throws Exception {
        String xml = Utils.loadString(name);
        SqlMap sqlMap = unmarshallXML(xml );
        return sqlMap;
    }
}

  OneAPM for Java 能够深入到所有 Java 应用内部完成应用性能管理和监控,包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。

时间: 2024-11-08 19:06:18

郑州尚学堂:在 Java 中如何更高效地存储和管理 SQL 语句?的相关文章

在 Java 中如何更高效地存储和管理 SQL 语句?

[编者按]还在为管理 Java 代码中的 SQL 语句而烦恼吗?让 Zemian 帮你摆脱困境吧!本文系 OneAPM 工程师编译整理 注意:使用java.util.Properties#loadFromXML其实会更简单! 如果使用的是普通的.没有任何外部类库的 Java JDBC,那么就必须得自己去管理 SQL 语句.很不幸的是,Java String 并不支持多行结构,所以开发者必须使用许多引号+连接符来拼接语句,这会使得 SQL 语句非常难于阅读和管理.同时,这也使得维护和测试(尝试从

java中的基本数据类型一定存储在栈中吗?

首先说明,"java中的基本数据类型一定存储在栈中的吗?”这句话肯定是错误的. 下面让我们一起来分析一下原因: 基本数据类型是放在栈中还是放在堆中,这取决于基本类型在何处声明,下面对数据类型在内存中的存储问题来解释一下: 一:在方法中声明的变量,即该变量是局部变量,每当程序调用方法时,系统都会为该方法建立一个方法栈,其所在方法中声明的变量就放在方法栈中,当方法结束系统会释放方法栈,其对应在该方法中声明的变量随着栈的销毁而结束,这就局部变量只能在方法中有效的原因 在方法中生明的变量可以是基本类型的

java中的基本数据类型一定存储在栈中的吗?

首先说明,"java中的基本数据类型一定存储在栈中的吗?”这句话肯定是错误的. 下面让我们一起来分析一下原因: 基本数据类型是放在栈中还是放在堆中,这取决于基本类型在何处声明,下面对数据类型在内存中的存储问题来解释一下: 一:在方法中声明的变量,即该变量是局部变量,每当程序调用方法时,系统都会为该方法建立一个方法栈,其所在方法中声明的变量就放在方法栈中,当方法结束系统会释放方法栈,其对应在该方法中声明的变量随着栈的销毁而结束,这就局部变量只能在方法中有效的原因 在方法中声明的变量可以是基本类型的

Jvm(28),理解升级----java中的基本数据类型一定存储在栈中吗

首先说明,"java中的基本数据类型一定存储在栈中的吗?"这句话肯定是错误的. 下面让我们一起来分析一下原因: 基本数据类型是放在栈中还是放在堆中,这取决于基本类型在何处声明,下面对数据类型在内存中的存储问题来解释一下: 一:在方法中声明的变量,即该变量是局部变量,每当程序调用方法时,系统都会为该方法建立一个方法栈,其所在方法中声明的变量就放在方法栈中,当方法结束系统会释放方法栈,其对应在该方法中声明的变量随着栈的销毁而结束,这就局部变量只能在方法中有效的原因 在方法中声明的变量可以是

ORACLE和SYBASE数据库中实现数据查询条数限制的SQL语句实现

一.概述 对于某些需要通过数据库与大量数据打交道的软件来说,处理性能相当的重要.为了保证软件能够将所有数据处理完而不至于崩溃,分批处理的思想应运而生.分批处理的具体做法是编写SQL语句,每次返回规定条数的数据给软件处理,待这一批数据处理完之后,再接着处理下一批. 本文通过对具体的数据库表(tb_employeeinfo)的操作过程,展示了ORACLE和SYBASE数据库中分批处理SQL语句的编写方法. 二.ORACLE数据库中的处理 首先,建立tb_employeeinfo表,其定义如下: be

程序中使用事务来管理sql语句的执行,执行失败时,可以达到回滚的要求。

1.设置使用事务的SQL执行语句 1 /// <summary> 2 /// 使用有事务的SQL语句 3 /// </summary> 4 /// <param name="sql"></param> 5 /// <param name="conn"></param> 6 /// <param name="tran"></param> 7 /// &l

25个让Java程序员更高效的Eclipse插件

Eclipse提供了一 个可扩展插件的开发系统.这就使得Eclipse在运行系统之上可以实现各种功能.这些插件也不同于其他的应用(插件的功能是最难用代码实现的).拥有合 适的Eclipse插件是非常重要的,因为它们能让Java开发者们无缝的开发基于J2EE和服务的应用程序.Eclipse的插件也能帮助他们开发不同 应用架构上的程序. 下面列出来的是25个最好的免费Eclipse插件,可以让开发者更高效的工作 . 提高代码质量的插件 1. FindBugs FindBugs可以帮你找到Java代码

java中变量、对象的存储

内容转自网上看到的一篇博文,讲的很不错. 1. 栈(stack)与堆(heap)都是Java用来在Ram中存放数据的地方.与C++不同,Java自动管理栈和堆,程序员不能直接地设置栈或堆.2. 栈的优势是,存取速度比堆要快,仅次于直接位于CPU中的寄存器.但缺点是,存在栈中的数据大小与生存期必须是确定的,缺乏灵活性.另外,栈数据可以共 享,详见第3点.堆的优势是可以动态地分配内存大小,生存期也不必事先告诉编译器,Java的垃圾收集器会自动收走这些不再使用的数据.但缺点是,由于要 在运行时动态分配

【Java基础】Java中的char是否可以存储一个中文字符之理解字符字节以及编码集

Java中的一个char采用的是Unicode编码集,占用两个字节,而一个中文字符也是两个字节,因此Java中的char是可以表示一个中文字符的. 但是在C/C++中由于采用的字符编码集是ASCII,只有一个字节,因此是没办法表示一个中文字符的. 解答了上面的浅显易懂的问题之后,下面彻底理清楚字符 字节以及编码的原理. 其实关于编码以及字节的问题,在腾讯实习生一面的时候也问到过,当时搞不懂面试官为什么会问这个问题,现在想想,这个问题还是很考验一个人的思考以及钻研深度的,而且这个问题远远比自己想象