查看: 74|回复: 6
FIDDLE证书问题，，无法安装！
阅读权限70
在线时间 小时
签到天数：7 天结帖率： (100/132)
发表于 昨天&19:34
123123.png (43.79 KB, 下载次数: 0)
昨天&19:34 上传
123.png (17.84 KB, 下载次数: 0)
昨天&19:33 上传
然后就没有然后了。。这是咋回事啊
123123.png (79.97 KB, 下载次数: 0)
昨天&19:33 上传
回答提醒：如果本帖被关闭无法回复，您有更好的答案帮助楼主解决，请发表至
可获得加分喔。友情提醒：本版被采纳的主题可在
帖子申请荣誉值，获得 1点 荣誉值,荣誉值可兑换终身vip用户组哦。快捷通道： →
阅读权限90
在线时间 小时
签到天数: 9 天结帖率： (17/20)
发表于 昨天&21:12
你就是点击你 图片里面箭头的链接&&安装FD 到手机 就可以了&&不是安装在电脑的&&是安装在手机里面的
阅读权限90
在线时间 小时
签到天数: 9 天结帖率： (17/20)
发表于 昨天&21:14
是在手机的浏览器访问你ip地址和端口& && &然后点击 第2个蓝色的链接 安装fd即可& &是在手机浏览器访问 不是在电脑访问啊
阅读权限70
在线时间 小时
签到天数: 7 天结帖率： (100/132)
发表于 昨天&21:22
是在手机的浏览器访问你ip地址和端口& && &然后点击 第2个蓝色的链接 安装fd即可& &是在手机浏览器访问 不 ...
手机也是一样的，问题是没有这个证书文件！
阅读权限90
在线时间 小时
签到天数: 9 天结帖率： (17/20)
发表于 昨天&21:28
安装成功会提示成功的&&看不到文件的
阅读权限90
在线时间 小时
签到天数: 9 天结帖率： (17/20)
发表于 昨天&21:28
你点击那个蓝色链接 没有提示你安装吗
阅读权限70
在线时间 小时
签到天数: 7 天结帖率： (100/132)
发表于 昨天&21:55
你点击那个蓝色链接 没有提示你安装吗
没有啊。。。
精易论坛 - 有你更精彩 /1
这次更新对易语言模块进行了加固，防止个人优秀模块被破解/反编译，更多新增功能请点击查看
拒绝任何人以任何形式在本论坛发表与中华人民共和国法律相抵触的言论，本站内容均为会员发表，并不代表精易立场!
揭阳精易科技有限公司申明:我公司所有的培训课程版权归精易所有，任何人以任何方式翻录、盗版、破解本站培训课程，我们必将通过法律途径解决！
公司简介：揭阳市揭东区精易科技有限公司致力于易语言教学培训/易语言学习交流社区的建设与软件开发，多年来为中小企业编写过许许多多各式软件，并把多年积累的开发经验逐步录制成视频课程供学员学习，让学员全面系统化学习易语言编程，少走弯路，减少对相关技术的研究与摸索时间，从而加快了学习进度！
Powered byExcel中的这些#DIV/0! 、#N/A 、#VALUE! 、#NAME 、#NULL! 、#NUM! 、#REF!错误代码你都知道是什么吗？让我们一起来看一下吧，以后碰到了也知道从哪下手改公式了。#DIV/0!错误名称:&被零除&错误出错信息:公式或函数被零或空单元格除.错误原因及解决方案:
公式中如果包含明显的被零除或者引用了值为0的单元格，小编就不说了，如果不会改，数学老师会桑心的！
使用对空白单元格引用作除数，尤其注意，Excel会将其解释为0，相当于被零除。
1.将单元格引用更改到另一个单元格或者单元格中输入一个非零的数值作为除数.
2.可以在作为除数引用的单元格中输入值 #N/A,这样就会将公式的结果从 #DIV/0!更改为 #N/A,表示除数不可用.
3.使用 IF 函数来防止显示错误值.例如,如果产生错误的公式是=A5/B5,则可使用=IF(B5=0,&&,A5/B5).其中,两个引号代表了一个空文本字符串.#N/A错误名称:&值不可用&错误出错信息:某个值对于该公式或函数不可用.错误原因及解决方案:1.遗漏数据,取而代之的是#N/A或NA().注意:可以在数据还不可用的单元格中输入#N/A.公式在引用这些单元格时,将不进行计算,而是返回#N/A.
2.为查找函数的lookup_value参数赋予了不适当的值.
3.在未排序的数据表中,使用VLOOKUP,HLOOKUP或MATCH函数来定位值.
4.数组公式中使用的参数的行数或列数与包含数组公式的区域的行数或列数不一致.如果要在多个单元格中输入数组公式,请确认被公式引用的区域与数组公式占用的区域具有相同的行数和列数,或者减少包含数组公式的单元格.
5.内部函数或自定义工作表函数中缺少一个或多个必要参数.在函数中输入全部参数.
6.使用的自定义工作表函数不可用.确认包含此工作表函数的工作簿已经打开并且函数工作正常.#VALUE!错误名称:值错误出错信息:公式中所用的某个值是错误的数据类型.错误原因及解决方案:当用的参数或操作数类型错误时
1.当公式需要数字或逻辑值（例如TRUE/FALSE）时,却输入了文本.
2.输入或编辑了数组公式，然后按了 Enter.
选定包含数组公式的单元格或单元格区域,按F2编辑公式,然后按 Ctrl+Shift+Enter.
3.将单元格引用、公式或函数作为数组常量输入.
确认数组常量不是单元格引用、公式或函数.
4.为需要单个值(而不是区域)的运算符或函数提供了区域.将区域更改为单个值.更改数值区域,使其包含公式所在的数据行或列.
5.在某个矩阵工作表函数中使用了无效的矩阵.确认矩阵的维数对矩阵参数是正确的.京东桌面支持(jdhelpdesk)　
　文章为作者独立观点，不代表微头条立场
的最新文章
请关注京东桌面支持，精彩你会发现！本文针对于Linux系统中，VPN的使用方法进行详述本文针对于Mac系统中，vpn使用方法进行详述本文针对windows系统中vpn使用方法进行详述本文对vpn申请进行详述请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！本文主要介绍修改完密码无法打印的解决方案请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！iOS版咚咚正式回归请关注京东桌面支持，精彩你会发现！本文针对于Linux系统中，VPN的使用方法进行详述本文针对于Mac系统中，vpn使用方法进行详述本文针对windows系统中vpn使用方法进行详述本文对vpn申请进行详述新版SSLVPN重装上线，8.29凌晨2点进行全面升级！本文着重介绍解决输入法图标消失的问题请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！Excel中的这些#DIV/0! 、#N/A 、#VALUE! 、#NAME 、#NULL! 、#NUM!请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！请关注京东桌面支持，精彩你会发现！jdhelpdesk京东桌面支持！钻石品质，超人速度，全程时刻陪伴您身边，帮您排除一切IT烦恼，快联系我们吧：热门文章最新文章jdhelpdesk京东桌面支持！钻石品质，超人速度，全程时刻陪伴您身边，帮您排除一切IT烦恼，快联系我们吧：JAVA开发人员在编写SQL时最容易犯的10个错误
&原文网址：&10 More Common Mistakes Java Developers Make when Writing SQL&&或&http://blog.jooq.org//10-more-common-mistakes-java-developers-make-when-writing-sql/
JAVA开发人员在编写SQL时最容易犯的10个错误
&10 More Common Mistakes Java Developers Make whenWriting SQL&
I was positivelysurprised to see how popular my recent listing about10
Common Mistakes Java Developers Make when Writing SQLwas, bothon
my own blogand
on my syndication partner DZone. The popularity shows acouple of things:
（我十分惊讶的发现我最近列出的JAVA开发者在写SQL时最容易犯的10个错误有多受欢迎，都在我的博客和DZONE上，这说明了一些事情：）
l&How important SQL isto the professional Java world.
（在JAVA专业开发领域中有多重要）
l&How common it is toforget about some basic SQL things.
（忘记一些基本的SQL常识有多常见）
l&How well SQL-centriclibraries such asjOOQ
or MyBatisare responding to market needs, byembracing
SQL.An amusing fact is that users have even mentioned my blog post onSLICK’s mailing list. SLICK is
a non-SQL-centricdatabase access library in Scala. LikeLINQ (and LINQ-to-SQL) it focuses on language integration,not
on SQL code generation.
（SQL中心库比如JOOQ和MyBatis对市场需求的反应有多么的好，byembracing SQL,一个有趣的事实是用户甚至提到了我博客上贴的一篇“SLICK'smailing list”，SLICK是一个基于Scala的NON-SQL-centric 数据库访问库，像LINQ(还有LNQ-TO-LINQ)，它侧重语言整合，而不是SQL语句的产生。）
Anyway, the commonmistakes I listed previously are far from complete, so I will treat you to asequel of 10 subtly less common, yet equally interesting mistakes Javadevelopers make when writing SQL.
（无论如何，我之前列出的常见错误还没有完成，我会和你们再探讨一下后续10个没有那么常见的，JAVA开发者在写SQL时的犯的同样有趣的错误。）
一、 不使用PreparedStstements&Not usingPreparedStatements&
Interestingly, this mistake or misbelief still surfacesblogs,forums
and mailing lists many years after the appearance of JDBC, even if it isabout a very simple thing to remember and to understand. It appears that somedevelopers refrain from using PreparedStatements for any of these reasons:
（在JDBC出现很多年后，这个错误仍然在很多的博客、论坛以及邮件中出现，即使这是一个十分容易记住和理解的问题。Java开发人员拒绝使用PreparedStatement的原因有以下几个：）
l& They don’t know about PreparedStatements
（他们对Preparedstatement不了解。）
l& They think that PreparedStatements are slower
（他们认为Preparedstatement更慢。）
l& They think that writing a PreparedStatementtakes more effort
（他们认为写一个PreparedStatement更费劲。）
First off, let’s bust the above myths. In 96% of the cases, you’re betteroff writing a PreparedStatement rather than a static statement. Why? For simplereasons:
（首先，让我们来看看PreparedStatement的好处，在96%的情况下，使用PreparedStatements比使用静态语句要更好。为什么这么说呢？下面列出了几个简单的原因：）
1.&&&&&&&你可以不必再担心由于拼接字符串错误时而产生的语法错误。&You can omit syntax errors originating from
badstring concatenation when inlining bind values.&
因为使用PreparedStatement不需要拼接字符串，而使用Statement就需要进行字符串的拼接。
stringsql = &select * from people pwhere p.id = ? and p.name = ?&;
preparedstatement ps = connection.preparestatement(sql);
ps.setint(1,id);
ps.setstring(2,name);
如果使用拼接字符串就是这样写：
stringsql = &select * from people pwhere p.id = & + id + & and p.name = & +
这样就很容易出现拼接错误，如少写或者多写了引号！而且可读性还很差。
2.&&&&&&&你可以不必在担心由于拼接字符串产生一个不好的字符串连接导致的SQL注入。&You
can omit SQLinjection vulnerabilities from bad string concatenation when inlining bindvalues.&
String sql= &select * from tb_name where name= '&+varname+&' and passwd='&+varpasswd+&'&;
如果我们把[' or '1' ='1]作为varpasswd传入进来.用户名随意,看看会成为什么?
select *from tb_name = '随意' and passwd = '' or '1' = '1';
因为'1'='1'肯定成立,所以可以任何通过验证.更有甚者:把[';droptable tb_]作为varpasswd传入进来,则:
select *from tb_name = '随意' and passwd = '';drop table tb_（有些数据库是不会让你成功的,但也有很多数据库就可以使这些语句得到执行.）
而如果你使用预编译语句.你传入的任何内容就不会和原来的语句发生任何匹配的关系.只要全使用预编译语句,你就用不着对传入的数据做任何过虑.而如果使用普通的statement,有可能要对drop,;等做费尽心机的判断和过虑.
3.&&&&&&&当插入更多“复杂的”数据类型（如TIMESTAMP、binary data或者其他的）时，可以避免出现边缘现象（edge-cases）。&You
can avoid edge-cases when inlining more“sophisticated” data types, such as TIMESTAMP, binary data, and others.&
（边缘现象：出现值为null或“”的情况&个人理解&）（在修复bug的过程中就会碰到很多这类的问题！）
4.&&&&&&&你可以保持开启PreparedStatement一段时间而不用马上关闭，这样就可以使用新的绑定值去复用它。&You
can keep open PreparedStatements around for awhile, reusing them with new bind values instead of closing them immediately(useful in Postgres, for instance).&
（因为PreparedStatement是预编译语句，因为预编译语句有可能被重复调用.所以语句在被DB的编译器编译后的执行代码被缓存下来,那么下次调用时只要是相同的预编译语句就不需要编译,只要将参数直接传入编译过的语句执行代码中(相当于一个涵数)就会得到执行.这并不是说只有一个Connection中多次执行的预编译语句被缓存,而是对于整个DB中,只要预编译的语句语法和缓存中匹配.那么在任何时候就可以不需要再次编译而可以直接执行.而statement的语句中,即使是相同一操作,而由于每次操作的数据不同所以使整个语句相匹配的机会极小,几乎不太可能匹配.比如:
insertinto tb_name (col1,col2) values ('11','22');
insertinto tb_name (col1,col2) values ('11','23');
即使是相同操作但因为数据内容不一样,所以整个个语句本身不能匹配,没有缓存语句的意义.事实是没有数据库会对普通语句编译后的执行代码缓存.
当然并不是所以预编译语句都一定会被缓存,数据库本身会用一种策略,比如使用频度等因素来决定什么时候不再缓存已有的预编译结果.以保存有更多的空间存储新的预编译语句.）
5.&&&&&&&你可以在更多复杂的数据库中使用自适应游标共享（adaptive cursor sharing）（Oracle中提到），这对于新设定的绑定值，可以防止SQL语句的硬解析（hard-parsing）。&You
can make use of adaptive cursor sharing (Oracle-speak)
in moresophisticated databases. This helps prevent hard-parsing SQL statements forevery new set of bind values.&
（硬解析的弊端：硬解析即整个SQL语句的执行需要完完全全的解析，生成执行计划。而硬解析，生成执行计划需要耗用CPU资源，以及SGA资源。在此不得不提的是对库缓存中闩的使用。闩是锁的细化，可以理解为是一种轻量级的串行化设备。当进程申请到闩后，则这些闩用于保护共享内存的数在同一时刻不会被两个以上的进程修改。在硬解析时，需要申请闩的使用，而闩的数量在有限的情况下需要等待。大量的闩的使用由此造成需要使用闩的进程排队越频繁，性能则逾低下。------参考：Oracle硬解析与软解析以及Oracle
SQL的硬解析和软解析）
Convinced? Yes. Note, there are some rare cases when you actually want toinline bind values in order to give your database’s cost-based optimiser someheads-up about what kind of data is really going to be affected by the query.Typically,
this results in “constant” predicates such as:
（确定吗？ 是的，注意，当你真的想要通过内联绑定值（inline bind values：我个人理解是拼接字符串，就是Statement的那种SQL写法 ）来优化你的数据库的开销的话，会出现一些很罕见的问题，那就是哪些数据真的会影响你的查询。具有代表性的是常量的判断，比如：）
l& DELETED = 1
l& STATUS = 42
But it shouldn’t result in “variable” predicates such as:
（而不是一些变量的判断比如：）
l& FIRST_NAME LIKE “Jon%”
l& AMOUNT & 19.95
Note that modern databases implement bind-variable peeking. Hence, bydefault, you might as well use bind values for all your query parameters. Notealso that higher-level APIs such asJPA
CriteriaQuery orjOOQ
will help you generate PreparedStatements and bind values very easily andtransparently when writing embedded JPQL or embedded SQL.
（现代数据库实现了绑定变量窥探（bind-variable peeking）。因此，一般情况下，你也可以在所有的查询参数上使用绑定值。注意一些高级的API比如JPA、JOOQ可以帮助你在写嵌入式的JPQL和SQL时十分简单和明显的产生PreparedStatment和绑定变量）
&&&&&& More background info:
（更多信息可以参考：）
Caveats of bind value peeking: An interestingblog
post by Oracle Guru Tanel Poder on the subjectCursor sharing. An interestingStack
Overflow question.
参考资料：
Oracle自适应共享游标
Oracle绑定变量窥探
&&&&&& bind variable peeking
The Cure（解决方法）：
&&&&&& By default, always use PreparedStatements instead ofstaticstatements. By default, never inline bind valuesinto
&&&&&& 默认情况下，总是使用PreparedStatement来代替静态语句。绝不要内联绑定值（拼接字符串）到你的SQL语句上（后面这句话，我的理解是像使用Statement时的那种SQL的写法：如“select
* from user_tabwhere username = ” + username + “ and password = ” + password
二、 返回太多列&Returning too many columns&
This mistake is quite frequent and can lead to very bad effects both inyour database’s execution plan and in your Java application.
（这个错误很频繁的出现在数据库的执行计划和java应用程序中。）
（执行计划可以参考：优化SQL查询：如何写出高性能SQL语句和SQL点滴27—性能分析之执行计划）
l& 让我们先来看看对于java应用程序的影响：&Bad effects on the Javaapplication:&
If you’re selecting * (star) or a “default” set of 50 columns, which you’rereusing among various DAOs, you’re transferring lots of data from the databaseinto a JDBC ResultSet. Even if you’re not reading the data from the ResultSet,it
has been transferred over the wire and loaded into your memory by the JDBCdriver. That’s quite a waste of IO and memory if youknowthat you’re only going to need 2-3 of those columns.
（如果你是为了将某些数据重用于不同的DAO层中，而查询出所有数据或者默认的50列的数据，这样，将会有大量的数据从数据库读入到JDBC结果集中。即使你可能不会读取到（使用到）所有结果集中的数据。但是，它已经通过JDBC驱动从线路中加载到了你的内存中。如果你知道你仅仅打算使用那些列中的2至3条数据，你会发现那将很浪费IO和内存。）
也就是说，如果你只是需要数据库中2-3列的数据，但是你通过使用(SELECT * …)查询出了所有数据。这将是一件很浪费IO和内存的事。
This was obvious, but beware also of…
这（问题的严重性）也就显而易见了，但是也要小心…
l& 让我们再来看看对于数据库的执行计划的影响：&Bad effectson the database execution plan:&
&&&&&& Theseeffects may actually be much worse than the effects on the Java application.Sophisticated databases perform a lot of SQL transformation when calculatingthe bestexecution plan for yourquery.It
may well be that some parts of your query can be“transformed away”, knowing that they won’t contribute to theprojection (SELECT clause) or to thefilteringpredicates. I’verecently blogged about this in the context of schema
meta data:
schema meta data impacts Oracle querytransformations
（事实上，这个错误对于数据库执行计划的影响比对JAVA应用程序的影响更严重。当为了给你的SQL语句计算最佳的执行计划时，复杂的数据库会进行大量的SQL转换。It may well be that some parts of your query can be “transformedaway”, knowing that they won’t contribute to the projection (SELECT clause) orto the filtering predicates. 相关内容参考：How
schema meta data impacts Oracle querytransformations）
&&&&&& Now,this is quite a beast. Think about a sophisticated SELECT that will join twoviews:
（现在，这个是十分可怕的。想想一个加入两个视图的复杂的查询：）
2.FROMcustomer_view c
3.JOINorder_view o
4. ON c.cust_id= o.cust_id
Each of the views that are joined to the above joined table reference mightagain join data from dozens of tables, such as CUSTOMER_ADDRESS, ORDER_HISTORY,ORDER_SETTLEMENT, etc. Given the SELECT *projection,your
database has no choice but to fully perform the loading of all thosejoined tables, when in fact, the only thing that you were interested in wasthis:
每个关联了上面关联的两张表的引用的视图也许还需要关联很多张表的数据。比如：CUSTOMER_ADDRESS, ORDER_HISTORY, ORDER_SETTLEMENT,等。使用select *查询，你的数据库除了只能够执行加载所有的那些关联的表，别无他法。但你实际上只需要这些数据：
1.SELECTc.first_name, c.last_name, o.amount
2.FROMcustomer_view c
3.JOINorder_view o
4.ON c.cust_id= o.cust_id
&&&&&& 因此，要尽量避免使用SELECT *。
A good database will transform your SQL in a way that most of the “hidden”joins can be removed, which results in much less IO and memory consumptionwithin the database.
一个好的数据库会转换你的SQL，将大部分不需要的关联移除，来减少IO操作和数据库的内存消耗。
The Cure（解决方法）:
Never execute SELECT *. Never reuse the same projection for variousqueries.Always try to reduce the projection to the datathat you really need.
绝对不要使用SELECT *（这样的查询语句）。永远不要在不同的查询中复用同一个规则，总是尝试将查询减少为你真正需要的数据。
Note that this can be quite hard to achieve with ORMs.
&&&&&& 注意：通过ORMs（对象-关系映射（Object/Relation Mapping，简称ORM）），这是很难实现的。
三、认为JOIN是SELECT的子句&Thinking that JOIN is aSELECT clause&
This isn’t a mistake with a lot of impact on performance or SQLcorrectness, but nevertheless, SQL developers should be aware of the fact thatthe JOIN clause is not part of the SELECT statement per se. TheSQL
standard 1992 defines atable reference as such:
（这不是一个对性能或者SQL准确性带来很多影响的错误，但尽管如此，SQL开发人员应该意识到JOIN子句不是SELECT语句的一部分的事实。SQL standard 1992定义了一个表引用像这样（如下）：）
6.3 &tablereference&
&tablereference& ::=& //表引用
&&& &table name& [ [ AS ] &correlationname&&& //表名 AS相关名称
&&&&& [ &left paren& &derived columnlist& &right paren& ] ] //（派生列列表）
& | &derived table& [ AS ]&correlation name&&& //派生表 AS相关名称
&&&&& [ &left paren& &derived columnlist& &right paren& ]&& //(派生列列表)
& | &joined table&&&&&& //连接表&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
The FROM clause and also thejoined table can then make use of
suchtable references:
（FROM子句以及the joined table（被连接的表）可以利用这样的表引用：）
7.4 &fromclause&
&fromclause& ::=
&&& FROM &table reference& [ {&comma& &table reference& }... ]
7.5 &joinedtable&
&joinedtable& ::=
&&& &cross join&
& | &qualified join&
& | &left paren& &joined table&&right paren&
&crossjoin& ::=
&&& &table reference& CROSS JOIN&table reference&
&qualifiedjoin& ::=
&&& &table reference& [ NATURAL ] [&join type& ] JOIN
&&&&& &table reference& [ &joinspecification& ]
Relational databases are very table-centric. Many operations are performedon physical, joined or derived tables in one way or another.Towrite SQL effectively, it is important
to understand that theSELECT .. FROM clause expects a comma-separated list oftable references in whatever form they may be provided.
（关系型数据库是非常以表为中心的。许多操作是在物理表、连接表或者派生表中以一种或另一种方式执行的。为了有效的编写SQL，重要的是要理解SELECT...FROM子句是一个以逗号分隔的表引用列表。）
Depending on the complexity of the table reference, some databases alsoaccept sophisticated table references in other statements, such as INSERT,UPDATE, DELETE, MERGE. SeeOracle’s
manuals for instance, explaining how to create updatable views.
（根据表引用的复杂性，在其他的语句中，数据库也接收复杂的表引用。例如：INSERT, UPDATE, DELETE, MERGE。通过Oracle’smanuals for instance这篇文章，可以查看关于如何创建可更新的视图的解释说明。）
The Cure（解决方法）：
Always think of your FROM clause to expect a table reference as awhole. If you write aJOIN
clause, think of thisJOIN clause to be part of a complex table reference:
（总的来说，总是把FROM子句认为是一个表引用。如果你写了一个JOIN子句，就把这个JOIN子句认为是一个复杂表引用的一部分：）
1.SELECTc.first_name, c.last_name,o.amount
4. customer_view c
5. JOINorder_view o
6. ON c.cust_id= o.cust_id
四、使用以前的ANSI JOIN语法&Usingpre-ANSI JOIN syntax&
from&T1,&T2
where&where_filter
&&&&这是ANSI SQL 1989引入的旧语法，使用逗号来分隔联接表，在where子句中指定联接字段。这种语法仅支持cross&join和inner&join，不支持outer&join。
from&T1&&join_type&&join&T2&on&&on_filter&
where&where_filter
&&&&这是ANSI SQL 1992引入的新语法，使用join关键字来分隔联接表，在on子句中指定联接字段。这种语法增加了对outer&join的支持。
以上两种语法都是ANSI SQL标准支持的，因此SQL Server也都支持。
在SQL Server增加对ANSI SQL 1992语法的支持之前，已经有了对outer&join的实际需求，因此T-SQL使用了专属的语法来支持outer&join，*=和=*分别代表left&outer&join和right&outer&join。该专属语法并不支持full
outer&join，也不属于ANSI SQL标准。
SQL Server 2005中建议不使用该专属语法（&*=&&或&=*&），但为了向后兼容，允许在兼容级别设置为80或更低的情况下继续使用，但是在将来的SQL
Server版本中，即使在向后兼容模式下，也不支持该语法。
上面一段来自：.cn/s/blog_7d2afc6c0100q3vk.html（JOIN语句的不同ANSI版本）
Nowthat we’ve clarified how table references work (see the previous point), itshould become a bit more obvious that the pre-ANSI JOIN syntax should beavoided at all costs. To execution plans, it usually makes no difference
if youspecify join predicates in the&JOIN .. ON&clauseor in theWHERE&clause.But
from a readability and maintenance perspective, using the&WHERE&clausefor both filtering predicates and join predicates is a major quagmire. Considerthis simple
（现在，我们已经讲清了表引用是如何工作的（详情看前面几点），以前的ANSI JOIN语法要不惜一切代价的避免应该变的很显然了。对于执行计划，如果你在JOIN...ON子句或者在WHERE子句中指定连接词，这通常是没有区别的。但是从可读性和可维护性的角度考虑，同时对过滤关键词（filtering predicates）和连接关键词（join
predicates）使用WHERE子句是一个主要的困境。看一个简单的例子：）
1.SELECTc.first_name, c.last_name, o.amount
2.FROM customer_viewc,
3. order_view o
4.WHERE o.amount &100
5.ANDc.cust_id = o.cust_id
6.AND c.language='en'
Canyou spot the
join predicate? What if we joined dozensof tables? This gets much worse when applying proprietary syntaxes for outerjoin, such asOracle’s&(+)&syntax.
（你能找出JOIN关键词吗？如果我们连接了几十张表呢？这对于应用外连接（outer join）专有语法将变得更糟糕，例如Oracle’s
(+) syntax这篇文章讲到的。）
我对上面一段代码的理解：（意思是不要省略JOIN连接词的写法，正确的写法是：
SELECT c.first_name,c.last_name, o.amount
FROM customer_view c
JOIN order_view o ONc.cust_id = o.cust_id AND c.language = 'en'
WHERE o.amount & 100
虽然这两段代码具有相同的执行计划，但是正确的写法在可读性和维护性方面都比例子给的代码要好）
TheCure（解决方法：
Always use the ANSI JOIN syntax. Never put JOIN predicates into theWHERE clause. There is absolutely no advantage to using the pre-ANSI JOINsyntax.
（总是使用ANSI JOIN语法&我的理解是使用最新的、标准的JOIN语法，不要再使用以前的JOIN语法&。绝不要将JOIN放在WHERE子句里面。使用以前的ANSI JOIN语法是绝对无利的。）
五、写LIKE时忘记写escape&Forgetting to escape input to the LIKE predicate&
The&SQL standard 1992&specifies the&like
predicate&as such:
（92版的SQL标准提出的LIKE是这样的：）
8.5 &likepredicate&&&
&like predicate& ::=&&& //LIKE谓词
&match value& [ NOT ] LIKE&pattern&&&&& //匹配值 [NOT]LIKE规则
[ ESCAPE &escape character& ]&&&& // ESCAPE
The&ESCAPE&keywordshould be used almost always when allowing for user input to be used in yourSQL queries. While it
may be rare that the percent sign (%) is actuallysupposed to be part of the data, the underscore (_) might well be:
（当在允许用户（进行）输入（操作）时，ESCAPE关键字都应该在你的查询语句中被使用。虽然以百分号“%”作为数据的一部分是不常见的（虽然数据中出现百分号“%”的情况是很少的），但是出现下划线“_”还是很常见的：）
3.WHEREt.x LIKE'some!_prefix%'ESCAPE'!'
上面的含义就是查询出以some_prefix开头的x数据。
如果想在SQL LIKE里查询有下划线'_'或是'%'等值的记录，直接写成like'XXX_XX'，则会把'_'当成是like的通配符。SQL里提供了
escape子句来处理这种情况，escape可以指定like中使用的转义符是什么，而在转义符后的字符将被当成原始字符，这和C里的'\'很像，但是escape要求自定义一个转义符，而不是指定了'\'字符。如：
select *from user_all_tables where table_name like 'YW_%' escape '_'
上面的含义是查出当前用户表下所有以'YW_'开头的表，其中第一个'_'是转义符，第二个是被转义的字符，等效可以写成：
select *from user_all_tables where table_name like 'YW\_%' escape '\'&
上面两段参考：/Render/archive//1258086.html
SQL Like 通配符特殊用法：Escape参考：/icebutterfly/archive//2340313.html（SQL
Server：SQL Like通配符特殊用法：Escape）
The Cure（解决方法）:
Always think of proper escaping when using the LIKE predicate.
（当使用LIKE关键词时总是适当的选择ESCAPE。）
六、 认为NOT(A IN(X,Y))和A IN(X,Y)的布尔值是相反的&Thinkingthat NOT(A IN(X,Y)) is the boolean inverse of A IN(X,Y)&
This one is subtlebut very important with respect toNULLs! Let’s review whatA IN (X,Y)
really means:
（这个错误虽然很微妙，但是再处理NULL值时很重要。让我们回顾下AIN (X, Y)的真正含义是什么：）
A IN (X, Y)
is the same as&&& A = ANY (X, Y)
is the same as&&& A = X OR A = Y
When at the same time,&NOT (A IN (X, Y))&really means:
（同时，NOT (A IN (X, Y))的真正含义：）
&&&&&&&&&&&&&&&&&
NOT (A IN(X, Y))
is the same as&&& A NOT IN (X, Y)
is the same as&&& A != ANY (X, Y)
is the same as&&& A != X AND A != Y
That looks like the boolean inverse of the previous predicate, but itisn’t! If any ofX
orY isNULL, theNOT
IN predicate will result inUNKNOWN whereas theIN
predicate might still return a boolean value.
（他们看起来是布尔相反的意思，但不是的。如果X和Y中有一个为NULL，则在NOT IN中的结果是UNKNOWN，然而在IN中的结果仍然是一个布尔值。）
Or in other words, when A IN (X, Y)yieldsTRUE
or FALSE,NOT(AIN (X, Y)) may still yieldUNKNOWN
instead ofFALSE or TRUE. Note, that this is also true if theright-hand side
of theIN predicate is a subquery.
（或者换句话说，当A IN (X, Y)的值为TRUE或FALSE，NOT(A IN (X, Y))的值可能仍然是UNKNOWN而不是FALSE或TRUE。注意：如果右手边的IN里面是个子查询，这个也是TRUE。）
Don’t believe it? See this SQL Fiddle
for yourself. It shows that the following query yields no result:
（不相信这些？自己去看这里：SQL Fiddle。它指出了下面的查询没有结果：）
2.WHERE 1IN (NULL)
3.UNIONALL
4.SELECT 2
5.WHERENOT(1 IN(NULL))
More details can be seen in my
previous blog post on that subject, which also shows some SQL dialect incompatibilities in that area.
（详细信息请看我以前的博客：my previous blogpost on that subject，它也展示了一些SQL方言在哪方面不一致的问题。）
The Cure（解决方法）:
Beware of the NOT IN predicate when nullable columns are involved!
（当涉及到允许为NULL的列时当心NOT IN（的使用））
So in fact,this can be said:
IDNOT IN (1, NULL) is equivalent to
NOT(ID IN (1, NULL)), equivalent to
NOT(ID = ANY(1, NULL)), equivalent to
NOT(ID = 1 OR ID = NULL), equivalent to
NOT(ID = 1) AND NOT (ID = NULL), which is always UNKNOWN
七、 认为NOT (A IS NULL) 和A IS NOT NULL)是相同的&Thinking that NOT (A IS NULL) is the same as A IS NOTNULL&
Right, so weremembered that SQL implements three-valued logic when it comes to handling NULL.That’s why we can use theNULL predicate to check for
NULLvalues.Right? Right.
（没错，所以我们记得当出现NULL值情况的时候，SQL实现了三值逻辑（三值逻辑：.cn/s/blog_a10cc2.html）。那就是我们能够用NULL检查NULL值的原因。对吗？对。）
But even the NULL predicate is subtle.Beware that the two following predicates are only equivalent for row valueexpressions of degree
（但是甚至NULL也是不易察觉的（容易遗漏的）。注意以下两个行值表达式只等价于行值表达式的值为1（的情况）：）
NOT (A ISNULL) is not the same as A IS NOT NULL
（NOT (A IS NULL)和A IS NOT NULL是不等价的。）
If A is a row value expression with a degree of more than 1,then the truth table is transformed such that:
（如果A是一个大于1的行值表达式，那真实表被转换像这样：）
l&A IS NULL yields true only if all values in
只有A中所有值为NULL时，A ISNULL为TRUE。
l& NOT(A IS NULL)yields false only if all values inA
只有A中所有值为NULL时，NOT(A IS NULL)为FALSE。
l& A IS NOT NULL yields true only if all values in AareNOT NULL
只有A中所有值为NOT NULL时，A ISNOT NULL为TRUE。
l& NOT(A IS NOT NULL)yields false only if all values in AareNOT
只有A中所有值为NOT NULL时，NOT(AIS NOT NULL)为FALSE。
See more details in my previous
blog post on that subject.
（详细内容请看我的前一篇博客：http://blog.jooq.org//row-value-expressions-and-the-null-predicate/ ）
The Cure（解决方法）:
When using row value expressions, beware of the NULL predicate, which mightnot work as expected.（当使用行值表达式时，留意NULL这个词，它可能不按你预想的工作。）
八、 在支持行值表达式的地方不使用行值表达式&Not using row value expressions where they are supported&
Row value expressions are an awesome SQL feature. When SQL is a verytable-centric language, tables are also very row-centric. Row value expressionslet you describe complex predicates much more easily,
by creating localad-hoc rows that can be compared with other rows of the same degree and rowtype. A simple example is to query customers for first names andlast names at the same time.
（行值表达式是SQL中一个非常棒的特性。同时SQL是一个非常以表为中心的语言，表又是非常以行为中心的。行值表达式可以让你更容易的描述出复杂的谓词，by creating local ad-hoc rows that can becompared with other rows of the same degree and row type.一个简单的例子就是同时查询顾客的名字和姓氏。）
1.SELECTc.address
2.FROM customer c,
3.WHERE(c.first_name, c.last_name) = (?, ?)
As can be seen, this syntax is slightly more concise than the equivalentsyntax where each column from the predicate’s left-hand side is compared withthe corresponding column on the right-hand side. This is particularly true ifmany
independent predicates are combined with AND. Using row value expressionsallows you to combine correlated predicates into one. This is most useful forjoin expressions on composite foreign keys:
（在通过谓词左边的每一列和相对应的右边的列比较可以看出这个语法比同等的语法要稍微简洁些。特别是许多独立的谓词和AND结合的时候。使用行值表达式允许你将相关联的谓词组合在一起。对于复合外键上的连接表达式，这是最有用的：）
1.SELECT c.first_name,c.last_name, a.street
2.FROM customer c
3.JOIN address a
4. ON (c.id,c.tenant_id) = (a.id, a.tenant_id)
Unfortunately, not all databases support row value expressions in the sameway. But the SQL standard had defined them already in1992,
and if you use them, sophisticated databases like Oracle or Postgres canuse them for calculating better execution plans. This is explained on thepopularUse
The Index, Luke page.
(不幸的是，不是所有的数据库都以相同的方式支持行值表达式。但是SQL标准已经在1992中对行值表达式进行了定义，如果你使用行值表达式,像Oracle或者PostgreSQL这些复杂的数据库就可以使用行值表达式来计算更好的执行计划。在Use The Index, Luke这个页面有相关的解释。)
The Cure（解决方法）:
Use row value expressions whenever you can. They will make your SQL moreconcise andpossiblyeven faster.（能够使用行值表达式的地方就用行值表达式。这会使你的SQL语句更加简洁甚至更快。）
九、不定义足够多的约束&Not defining enough constraints&
So, I’m going to cite Tom Kyte
The Index,Luke again. You cannot have enough constraints in your meta data. First off,constraints help you keep your data from corrupting, which is already veryuseful. But to me, more importantly, constraints will
help the database performSQL transformations, as the database can decide that
（因此，我又要引用Tom Kyte和Use
The Index, Luke。在你的元数据中没有足够的约束。首先，约束可以帮助防止你的数据变质，这已经很有用了。但是对于我来说，更重要的是约束可以有助于数据库执行SQL转换，正如数据库可以决定那些：）
l& Some values are equivalent
有些值是等价的
l& Some clauses are redundant
有些子句是多余的
l& Some clauses are “void” (i.e. they will notreturn any values)
有些子句是“空”的（也就是：它们不会反回任何值）
Some developers may think that constraints are slow. The opposite is thecase, unless you insert lots and lots of data, in case of which you can eitherdisable constraints for a large operation, or use a temporary “load table”without
constraints, transferring data offline to the real table.
（一些开发者可能认为（加）约束会（使运行速度）变慢。相反，除非你插入许多许多的数据，对于大型的操作你可以禁用约束，或者使用一个没有约束的临时“加载表”（简化SQL语句的重要方法就是采用临时表暂存中间结果，但是，临时表的好处远远不止这些，将临时结果暂存在临时表，后面的查询就在tempdb中了，这可以避免程序中多次扫描主表，也大大减少了程序执行中“共享锁”阻塞“更新锁”，减少了阻塞，提高了并发性能。&参考：优化SQL查询：如何写出高性能SQL语句&），线下再转移数据到真实的表。）
The Cure（解决方法）:
Define as many constraints as you can. They will help your database toperform better when querying.（尽可能多的定义约束。这样你的数据库会更好的执行查询（操作）。）
十、认为50毫秒是比较快的查询&Thinkingthat 50ms is fast query execution&
The NoSQL hype is still ongoing, and many companies still think they’reTwitter or Facebook in dire need of faster, more scalable solutions, escapingACID and relational models to scale horizontally. Some may succeed (e.g.Twitter
or Facebook), others may run into this:
（NoSQL炒作仍然在进行中，许多公司仍然认为他们是Twitter或者Facebook，急需更快、更可扩展的解决办法，脱离ACID（ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transactionprocessing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。）和关系模式横向扩展（SQL横向扩展：/china/msdn/library/data/sqlserver/ScalOutSQL.mspx?mfr=true）。有些可能会成功（如：Twitter、Facebook），其他的可能像下面一样：)
Found here:
/codinghorror/status/692545
For the others who are forced (or chose) to stick with proven relationaldatabases, don’t be tricked into thinking that modern databases are slow.They’re hyper fast. In fact, they’re so fast, they can parse your 20kb querytext,
calculate 2000-line execution plans, and actually execute that monster inless than a millisecond, if you and your DBA get along well and tune yourdatabase to the max.
（对于被迫（或者选择）坚持证明关系数据库的其他人，请不要认为现代数据库是很慢的。他们超级快。事实上，他们是如此的快，可以在不到一毫秒的时间内解析20kb的查询文本、计算出200行数据的执行计划并实际执行。如果你和你的数据库管理员（DBA：DatabaseAdministrator）相处的和谐，你的数据库将最大限度的运行好。）
They may be slow because of your application misusing apopular ORM,
or because that ORM won’t be able to produce fast SQL for your complexquerying logic. In that case, you may want to chose a more SQL-centric API likeJDBC,jOOQ
orMyBatis that will let you get back in control of your SQL.
（他们可能慢的原因是因为你的应用程序误用了流行的ORM框架，或者是因为ORM框架无法为你的复杂的查询逻辑产生出更快的SQL查询。对于这种情况，你可以选择一个以SQL为中的的API，如：JDBC、JOOQ、MyBatis，他们可以让你自己去编写SQL控制语句。）
So, don’t think that a query execution of 50ms is fast or even acceptable.It’s not.If
youget these speeds at development time, make sure you investigate executionplans. Those monsters might explode in production, where you have more complexcontexts and data.
（所以，不要认为一个50毫秒的查询是很快的甚至（认为这个速度）是可接受的。它不是。如果你开发时（的SQL语句运行速度）是这个速度的话，（最好先）确保你研究过执行计划。因为它们（The Monsters）可能在你更复杂的上下文以及数据中爆发。）
Conclusion&结论&
SQL is a lot of fun,but also very subtle in various ways. It’s not easy to get it right as myprevious blog post about10
common mistakeshas shown. But SQL can be mastered and it’s worth the trouble. Data is yourmost valuable asset. Treat data with respect and write better SQL.
&&&&&& SQL是非常有趣的，但是也非常的微妙。它不容易掌握，正如我前面发表的一篇博客（10 commonmistakes）里面提到的一样。但是SQL还是可以被掌控的，而且它值得我们去花功夫、值得我们去研究。（对于SQL开发人员来说）数据是你最宝贵的财富。（让我们）重视数据并且写出更好的SQL语句吧！
部分翻译内容参考了这里：http://blog.csdn.net/u/article/details/9981573
> 本站内容系网友提交或本网编辑转载，其目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请及时与本网联系，我们将在第一时间删除内容！
Java程序员编程时需要混合面向对象思维和一般命令式编程的方法,能否完美的将两者结合起来完全得依靠编程人员的水准: 技能(任何人都能容易学会命令式编程) 模式(有些人用&模式-模式&,举个例子,模式可以应用到任何地方,而且都可以归为某一类模式) 心境(首先,要写个好的面向对象程序是比命令式程序难的多,你得花费一些功夫) 但当Java程序员 ...
站的角度不同,看的问题不同吧,这里我也不做过多评论.不过,可以采用换一种方式看世界,用另外一种方式看java.sql,还是不错的.从这些观点中,找到自己想要的,收获自己感到意外的以下是top10 point,看了后,是否有兴趣继续,观者自行决定.1.忘掉NULL2.在Java内存中处理数据 3. 使用UNION代替UNION ALL 4.通过JDBC分页技术 ...
文章地址: http://blog.csdn.net/yuliqi0429/article/details/
对于学习 Scala 的 Java(TM) 开发人员来说,对象是一个比较自然.简单的入口点.在 本系列 前几期文章中,我介绍了 Scala 中一些面向对象的编程方法,这些方法实际上与 Java 编程的区别不是很大.我还向您展示了 Scala 如何重新应用传统的面向对象概念,找到其缺点,并根据 21 世纪的新需求重新加以改造.Scala 一直隐藏的一些重要内容将要现 ...
http://blog.csdn.net/phantomhu/archive//4337933.aspx
Scala 显然是一门有趣的语言,很适合体现语言理论和创新方面的新思想,但最终它要用在 “现实” 环境中,它必须能满足开发人员的某些需求并在 “现实” 环境中有一定的实用性. 了解 Scala 语言的一些核心功能之后,就能认识到
最近发布的 Google Web Toolkit (GWT) 是一组全面的 API 和工具,它支持用户几乎完全使用 Java(TM) 代码来创建动态 Web 应用程序.Philip McCarthy 回到了他广受欢迎的面向 Java 开发人员的 Ajax 系列,向您展示 GWT 能做什么,并帮助您确定它是否适合您. GWT(请参阅 参考资料)采用了一种不寻常的方式 ...
面向 Java 开发人员的 Ajax: 构建动态的 Java 应用程序 Ajax 为更好的 Web 应用程序铺平了道路 在 Web 应用程序开发中,页面重载循环是最大的一个使用障碍,对于 Java(TM) 开发人员来说也是一个严峻的挑战.在这个系列中,作者 Philip McCarthy 介绍了一种创建动态应用程序体验的开创性方式.Ajax(异步 JavaScri ...
Java开发人员必备的资料:Apache Jakarta Commons
Jakarta Commons是Jakarta的一个子项目,目的是创建和维护独立于其他框架和产品的程序包(packages).这些程序包是一些服务于小范围的有效组件的集合,通常适用于服务器端编程.
Apache Commons包估计是Java中使用最广发的 ...