Java开发者编写SQL语句时常见错误分别有哪些

介绍

今天就跟大家聊聊有关Java开发者编写SQL语句时常见错误分别有哪些,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

Java开发者对于面向对象编程思维与命令行编程思维的协调程度,取决于他们如下几种能力的水平:

技巧(任何人都可以编写命令行形式的代码)教条(有的人使用“模式,模式”的方式,即模式无处不在,并以名字作为标识)情绪状况(在初期,真正面向对象形式的代码比起命令式代码会更加难懂)。

但是,当Java开发人员编写SQL语句时,一切都变得不同了. SQL是一种说明式语言,与面向对象思想和命令式思想无关。在SQL语言中,查询非常容易表达。但它也不是那么容易以最佳或最正确地方式编写出来。开发人员不仅需要重新思考自己的编程模式,还需要从集合论的角度进行深入思考。

以下是Java开发人员使JDBC或jOOQ编写SQL语句时,<强>几种常见的错误:

<强> 1。忘记了空

误解空的含义可能是Java开发人员编写SQL最常犯的错误。这有可能是因为零也被称为未知,但也有其他的原因。当然如果它只被叫做未知,会更容易理解一些。另一个原因是,JDBC在获取数据,或绑定变量时,SQL中的零被映射到Java中的NULL。这可能会导致人们认为类似Java中NULL==NULL的情况,SQL中也存在零=NULL。

一个更离奇的误解空的例子是,当零谓词用于行值表达式时。

另一个微妙的问题产生与范围内随意抽查,对反连接中零含义的误解。

<强>解决办法

不断的训练自己。要时刻明确空的含义,每次你写SQL时,都要考虑:

对于零来说谓词是否正确?零是否影响该函数的结果? <强> 2。在Java内存中处理数据

一些Java开发者十分了解SQL特性。偶尔加入,零散的联盟,没什么问题。但如果遇到视窗功能,结果集分组等情况又怎么样呢?很多Java开发人员会把SQL数据加载到内存,把数据转换成一些适合的集合类型,以十分冗长的循环结构在集合上执行恼人数学运算(至少在Java 8改进容器之前是这样的)。

但一些SQL数据库除了支持SQL标准外,还支持先进的OLAP特性,执行效率更好,且更容易编写。一个非标准的例子就是甲骨文的模型子句。只是让数据库进行数据处理过程,将最终获取的结果加载到Java内存中。因为一些非常聪明的人已经优化了这些昂贵的产品,所以,事实上,通过向OLAP数据库上进行迁移,您将得到两个好处:

简洁。它可能使得在SQL中编写正确代码会比在Java中相对容易性能。该数据库将可能比你的要快,更重要的是,你不必再通过网络传输数百万条记录。<强>解决办法

每次你在Java中实现以数据为中心的算法时,要试着问问自己:有没有办法让数据库执行这些工作,而只把结果交付给我?

<强> 3。尽量使用,而不是联盟所有

相对于联盟,联盟所有需要额外的关键字显得相形见绌。如果在SQL标准已定义如下支持,那将会好很多:

联盟(允许重复)联盟不同(去掉重复)一般很少需要去除重复(有时去重甚至是错误的),而且对于具有很多列的大结果集,它往往很慢,因为这两个子查询需要排的序,每个元组都需要与随后的元组进行比较。

需要注意的是,即使SQL标准指定了INTERSECTALL和EXCEPTALL,但几乎没有任何数据库实现这些用处不大的操作。

<>强解决办法

你每次写到联盟时,要考虑下你是否实际上想写的是UNIONALL。

<强> 4。使用JDBC分页功能将大量结果分页

大多数数据库都支持通过限制. .抵消,. .开始,抵消。获取等子句以某种方式对结果进行分页。在没有对这些子句的支持下,但仍然有ROWNUM (Oracle)或ROW_NUMBER () () (DB2、SQL Server 2008和更低版本),这比在内存中分页要快得多,而且这对于大数据集更是明显。

<强>解决办法

只要使用那些子句或工具(如jOOQ),可以为你模拟上述分页子句。

<强> 5。将Java内存中实现连接

从SQL的发展的初期,一些开发商在面对SQL连接时仍然有一种不安的感觉。一直存在着一种固有的恐惧——加入速度缓慢。如果基于成本的优化器选择执行嵌套循环,创建一个连接表源之前,加载完整表到数据库内存,那速度确实十分缓慢。但很这少发生。通过适当的谓词,约束和索引,MERGEJOIN和HASHJOIN操作是非常快的。这与正确的元数据相关(我不用再举汤姆肚子的例子了)。然而,也有仍然可能有不少Java开发人要会从单独的查询中加载两个表到地图容器中,在Java内存中以某种方式进行连接操作。

Java开发者编写SQL语句时常见错误分别有哪些