ListString?list1=new?ArrayListString();
list1.add("str1");
for(String?value1?:?list1)
{
}
用编程实现图的存储一般有常见的有两种方式,第一种是邻接链表、第二种就是邻接矩阵.
邻接链表就是将图中的每一个点都单独作为一个单独链表的起点,为每个顶点保存一个链表.链表的每一个节点都记录了与之相邻的节点的信息.
邻接矩阵就是将图转换成一个二维数组,数组的x和y均表示图中每个节点到其他节点的连接状况,能连通用一种状态表示,不能连通用另外一中方式表示,这样就形成了一个笛卡尔积.也就是一个二维数组.
Java程序员编程时需要混合面向对象思维和一般命令式编程的方法,能否完美的将两者结合起来完全得依靠编程人员的水准：
技能（任何人都能容易学会命令式编程）模式（有些人用"模式-模式",举个例子,模式可以应用到任何地方,而且都可以归为某一类模式）心境（首先,要写个好的面向对象程序是比命令式程序难的多,你得花费一些功夫）
但当Java程序员写SQL语句时,一切都不一样了.SQL是说明性语言而非面向对象或是命令式编程语言.在SQL中要写个查询语句是很简单的.但在Java里类似的语句却不容易,因为程序员不仅要反复考虑编程范式,而且也要考虑算法的问题.
下面是Java程序员在写SQL时常犯的10个错误（没有特定的顺序）.
①.、忘掉NULL
Java程序员写SQL时对NULL的误解可能是最大的错误.也许是因为（并非唯一理由）NULL也称作UNKNOWN.如果被称作 UNKNOWN,这还好理解些.另一个原因是,当你从数据库拿东西或是绑定变量时,JDBC将SQL NULL 和Java中的null对应了起来.这样导致了NULL = NULL（SQL）和null=null（Java）的误解.
对于NULL最大的误解是当NULL被用作行值表达式完整性约束条件时.另一个误解出现在对于NULL 在 NOT IN anti-joins的应用中.
解决方法：
好好的训练你自己.当你写SQL时要不停得想到NULL的用法：这个NULL完整性约束条件是正确的?NULL是否影响到结果?
但是一些SQL数据库支持先进的（而且是SQL标准支持的）OLAP特性,这一特性表现更好而且写起来也更加方便.一个（并不怎么标准的）例子就 是Oracle超棒的MODEL分句.只让数据库来做处理然后只把结果带到Java内存中吧.因为毕竟所有非常聪明的家伙已经对这些昂贵的产品进行了优 化.所以呢实际上,通过将OLAP移到数据库,你将获得一下两项好处：
便利性.这比在Java中编写正确的SQL可能更加的容易.性能表现.数据库应该比你的算法处理起来更加快.而且更加重要的是,你不必再去传递数百万条记录了.
每次你使用Java实现一个以数据为中心的算法时,问问自己：有没有一种方法可以让数据库代替为我做这种麻烦事.
和UNION相比UNION ALL还需要额外的关键字.如果SQL标准已经规定了支持,那么可能会更好点.
UNION（允许重复）UNION DISTINCT （去除了重复）
移除重复行不仅很少需要（有时甚至是错的）,而且对于带很多行的大数据集合会相当慢,因为两个子select需要排序,而且每个元组也需要和它的子序列元组比较.
注意即使SQL标准规定了INTERSECT ALL和EXCEPT ALL,很少数据库会实现这些没用的集合操作符.
每次写UNION语句时,考虑实际上是否需要UNION ALL语句.
仅仅使用这些语句,那么一个工具（例如JOOQ）就可以模拟这些语句的操作.
从SQL的初期开始,当在SQL中使用JOIN语句时,一些开发者仍旧有不安的感觉.这是源自对加入JOIN后会变慢的固有恐惧.假如基于成本的 优化选择去实现嵌套循环,在创建一张连接表源前,可能加载所有的表在数据库内存中,这可能是真的.但是这事发生的概率太低了.通过合适的预测,约束和索 引,合并连接和哈希连接的操作都是相当的快.这完全是是关于正确元数据（今天这一节我不能够引用Tom Kyte的太多）.而且,可能仍然有不少的Java开发人员加载两张表通过分开查询到一个映射中,并且在某种程度上把他们加到了内存当中.
假如你在各个步骤中有从各种表的查询操作,好好想想是否可以表达你的查询操作在单条语句中.
通过复杂的连接,人们可能会对SQL语句中扮演关键角色的所有关系失去概念.特别的,如果这涉及到多列外键关系的话,很有可能会忘记在JOIN .. ON子句中增加相关的判断.这会导致重复的记录,但或许只是在特殊的情况下.有些开发者所以呢可能选择DISTINCT来消除这些重复记录.从三个方面来说 这是错误的：
它（也许）解决了表面症状但并没有解决问题.它也有可能无法解决极端情况下的症状.对具有很多列的庞大的结果集合来说它很慢.DISTINCT要执行ORDER BY操作来消除重复.对庞大的笛卡尔积集合来说它很慢,还是需要加载很多的数据到内存中.
根据经验,如果你获得了不需要的重复记录,还是检查你的JOIN判断吧.可能在某个地方有一个很难觉察的笛卡尔积集合.
这并不是一个过失,但是可能是缺少知识或者对于强悍的MERGE语句信心不足.一些数据库理解其它形式的更新插入（UPSERT）语句, 如 MYSQL的重复主键更新语句,但是MERGE在数据库中确是很强大,很重要,以至于大肆扩展SQL标准,例如SQL SERVER.
如果你使用像联合INSERT和UPDATE或者联合SELECT .. FOR UPDATE然后在INSERT或UPDATE等更新插入时,请三思.你完全可以使用一个更简单的MERGE语句来远离冒险竞争条件.
在介绍窗口函数之前,在SQL中聚合数据意味着使用GROUP BY语句与聚合函数相映射.在很多情形下都工作得很好,如聚合数据需要浓缩常规数据,那么就在join子查询中使用group查询.
使用窗口函数：
使SQL更易读（但在子查询中没有GROUP BY语句专业）提升性能,像关系数据库管理系统能够更容易优化窗口函数
当你在子查询中使用GROUP BY语句时,请再三考虑是否可以使用窗口函数完成.
SQL的ORDER BY语句支持很多类型的表达式,包括CASE语句,对于间接排序十分有用.你可能重来不会在Java内存中排序数据,因为你会想：
SQL排序很慢SQL排序办不到
如果你在内存中排序任何SQL数据,请再三考虑,是否不能在数据库中排序.这对于数据库分页数据十分有用.
①.0、一条一条地插入大量记录
JDBC"懂"批处理（batch）,你应该不会忘了它.不要使用INSERT语句来一条一条的出入成千上万的记录,（因为）每次都会创建一个新 的PreparedStatement对象.如果你的所有记录都插入到同一个表时,那么就创建一个带有一条SQL语句以及附带很多值集合的插入批处理语 句.你可能需要在达到一定量的插入记录后才提交来保证UNDO日志瘦小,这依赖于你的数据库和数据库设置.
总是使用批处理插入大量数据.
来自：OSChina
译者：oschina.net/translate/10-common-mistakes-java-developers-make-when-writing-sql
给你我的思路吧,我大概有三种方案,但三种方案的前提是数字不重复,我想这点是必须的
第一段：做最简单的遍历,也就是应用二重循环对a遍历,并在a遍历方法内遍历b然后逐条比较如果没有就加入一个,不过因为是数据不能随便添加最终你还是要重新new一个数组
这种做法的坏处就是两次循环相当于笛卡尔积,遍历内容过多,如果数据太大就不建议这种方案了
第二段：由于你用java来遍历,所以可以把b中的数据放入一个List集合里面,遍历a应用list的contain方法,如果存在就不加入,如果不存在就加入到list里面,最后再把list转换为数字
这种做法可能应用到其他类,所以在算法上不受自己控制
第三段：自己写一个算法,我的思路是首先对b数组排序,然后遍历a数组,并在a数组中通过折半查找b中是否存在a的元素,如果不存在就添加
以上不知道能否满足你.
您好,这样：
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
public class Exe1 {
// 日期格式
private String partten = "yyyy/MM/dd";
这段代码应该是由程序（例如Java）中生成的,where条件中 1=1 之后的条件是通过 if 块动态变化的.例如:
String sql="select * from table_name where 1=1";
if( conditon 1) {
where 1=1 是为了避免where 关键字后面的第一个词直接就是 "and"而导致语法错误.