$ cd /cygdrive/c/hadoop-0.16.0
$ mkdir test-in
$ cd test-in
#在 test-in 目录下创建两个文本文件, WordCount 程序将统计其中各个单词出现次数
$ echo "hello world bye world" >file1.txt
$ echo "hello hadoop goodbye hadoop" >file2.txt
$ cd ..
$ bin/hadoop jar hadoop-0.16.0-examples.jar wordcount test-in test-out
#执行完毕，下面查看执行结果：
$ cd test-out
$ cat part-00000
bye     1
goodbye  1
hadoop  2
hello    2
world   2

<configuration>
<property>
<name>fs.default.name</name>
<value>localhost:9000</value>
</property>
<property>
<name>mapred.job.tracker</name>
<value>localhost:9001</value>
</property>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
</configuration>

$ ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

$ cd /cygdrive/c/hadoop-0.16.0
$ bin/hadoop namenode –format 

$ bin/start-all.sh
$ ps –ef

$ bin/hadoop dfs -put ./test-in input
#将本地文件系统上的 ./test-in 目录拷到 HDFS 的根目录上，目录名改为 input
#执行 bin/hadoop dfs –help 可以学习各种 HDFS 命令的使用。
$ bin/hadoop jar hadoop-0.16.0-examples.jar wordcount input output
#查看执行结果:
#将文件从 HDFS 拷到本地文件系统中再查看：
$ bin/hadoop dfs -get output output
$ cat output/*
#也可以直接查看
$ bin/hadoop dfs -cat output/*
$ bin/stop-all.sh #停止 hadoop 进程

 Index or table scans(索引或者表扫描)：可能意味着需要更好的或者额外的索引。

Bookmark Lookups(书签查找)：考虑修改当前的聚集索引，使用复盖索引，限制SELECT语句中的字段数量。

Filter(过滤)：在WHERE从句中移除用到的任何函数，不要在SQL语句中包含视图，可能需要额外的索引。

Sort(排序)：数据是否真的需要排序？可否使用索引来避免排序？在客户端排序是否会更加有效率？

查看SQL Server图形执行计划时，可以查找的非常有用的一个东西就是查询优化器如何为给定的查询使用索引来从表中获取数据。通过查看是否有用到索引，以及索引如何被使用，都有助于判断当前的索引是否使得查询执行得尽可能的快。

将鼠标移到图形执行计划上的表名(以及它的图标)上面，就会弹出一个窗口，从它上面可以看到一些信息。这些信息让你知道是否有用到索引来从表中获取数据，以及它是如何使用的。这些信息包括：

·     Table Scan(表扫描)：如果看到这个信息，就说明数据表上没有聚集索引，或者查询优化器没有使用索引来查找。意即资料表的每一行都被检查到。如果资料表相对较小的话，表扫描可以非常快速，有时甚至快过使用索引。

因此，当看到有执行表扫描时，第一件要做的事就是看看数据表有多少数据行。如果不是太多的话，那么表扫描可能提供了最好的总体效能。但如果数据表大的话，表扫描就极可能需要长时间来完成，查询效能就大受影响。在这种情况下，就需要仔细研究，为数据表增加一个适当的索引用于这个查询。

假设你发现某查询使用了表扫描，有一个合适的非聚集索引，但它没有用到。这意味着什么呢？为什么这个索引没有用到呢？如果需要获得的数据量相对数据表大小来说非常大，或者数据选择性不高(意味着同一个字段中重复的值很多)，表扫描经常会比索引扫描快。例如，如果一个数据表有10000个数据行，查询返回1000行，如果这个表没有聚集索引的话，那么表扫描将比使用一个非聚集索引更快。或者如果数据表有10000个数据行，且同一个字段(WHERE条件句有用到这个字段)上有1000笔重复的数据，表扫描也会比使用非聚集索引更快。

查看图形执行计划上的数据表上的弹出式窗口时，请注意”预估的资料行数(Estimated Row Count)”。这个数字是查询优化器作出的多少个数据行会被返回的最佳推测。如果执行了表扫描且”预估的数据行数”数值很高的话，就意味着返回的记录数很多，查询优化器认为执行表扫描比使用可用的非聚集索引更快。

·     Index Seek(索引查找)：索引查找意味着查询优化器使用了数据表上的非聚集索引来查找数据。性能通常会很快，尤其是当只有少数的数据行被返回时。

·     Clustered Index Seek(聚集索引查找)：这指查询优化器使用了数据表上的聚集索引来查找数据，性能很快。实际上，这是SQL Server能做的最快的索引查找类型。

·     Clustered Index Scan(聚集索引扫描)：聚集索引扫描与表扫描相似，不同的是聚集索引扫描是在一个建有聚集索引的数据表上执行的。和一般的表扫描一样，聚集索引扫描可能表明存在效能问题。一般来说，有两种原因会引此聚集索引扫描的执行。第一个原因，相对于数据表上的整体数据行数目，可能需要获取太多的数据行。查看”预估的数据行数量(Estimated Row Count)”可以对此加以验证。第二个原因，可能是由于WHERE条件句中用到的字段选择性不高。在任何情况下，与标准的表扫描不同，聚集索引扫描并不会总是去查找数据表中的所有数据，所以聚集索引扫描一般都会比标准的表扫描要快。通常来说，要将聚集索引扫描改成聚集索引查找，你唯一能做的是重写查询语句，让语句限制性更多，从而返回更少的数据行。

绝大多数情况下，查询优化器会对连接进行分析，按最有效率的顺序，使用最有效率的连接类型来对数据表进行连接。但并不总是如此。在图形执行计划中你可以看到代表查询所使用到的各种不同连接类型的图标。此外，每个连接图标都有两个箭头指向它。指向连接图标的上面的箭头代表该连接的外部表，下面的箭头则代表这个连接的内部表。箭头的另一头则指向被连接的数据表名。

有时在多表连接的查询中，箭头的另一头指向的并不是一个数据表，而是另一个连接。如果将鼠标移到指向外部连接与内部连接的箭头上，就可以看到一个弹出式窗口，告诉你有多少数据行被发送至这个连接来进行处理。外部表应该总是比内部表含有更少的数据行。如果不是，则说明查询优化器所选择的连接顺序可能不正确(下面是关于这个话题的更多信息)。

首先，让我们来看看连接类型。SQL Server可以使用三种不同的技术来连接资料表：嵌套循环(nested loop)，散列(hash)，以及合并(merge)。一般来说，嵌套循环是最快的连接类型，但如果不可能使用嵌套循环的话，则会用到散列或者合并作为合适的连接类型。两者都比嵌套循环连接慢。

当连接大表时，则合并连接可能是最佳选项，而非嵌套循环连接。唯一的明确这一点的方式是对两者都进行测试以查看哪一个最有效率。

如果你怀疑某个查询速度慢的原因可能是因为它所使用的连接类型不理想，那么你可以使用连接提示来复盖查询优化器的选择。在使用连接提示之前，你需要花费一些时间去了解一下每种连接类型以及它们的工作方式。这是一个复杂的话题，超出了本文的讨论范围。

查询优化器选择最有效率的连接类型来连接数据表。例如，嵌套循环连接的外部表应该是连接的两个表中较小的那个表。散列连接也是一样，它的外部表应该是较小的那个表。如果你觉得查询优化器选择的连接顺序是错误的，可以使用连接提示来复盖它。

你常常会在图形执行计划上看到标识成”书签查找(Bookmark Lookup)”的图标。书签查找相当常见。书签查找的本质是告诉你查询处理器必须从数据表或者聚集索引中来查找它所需要的数据行，而不是从非聚集索引中直接读取。

打比方说，如果一个查询语句的SELECT,JOIN以及WHERE子句中的所有字段，都不存在于那个用来定位符合查询条件的数据行的非聚集索引中，那么查询优化器就不得不做额外的工作在数据表或聚集索引中查找那些满足这个查询语句的字段。

另一种引起书签查找的原因是使用了SELECT *。由于在绝大多情况下它会返回比你实际所需更多的数据，所以应该永不使用SELECT *.

从性能方面来说，书签查找是不理想的。因为它会请求额外的I/O开销在字段中查找以返回所需的数据行。

如果认为书签查找防碍了查询的性能，那么有四种选择可以用来避免它：可以建立WHERE子句会用到的聚集索引，利用索引交集的优势，建立覆盖的非聚集索引，或者(如果是SQL Server 2000/2005企业版的话)可以建立索引视图。如果这些都不可能，或者使用它们中的任何一个都会耗用比书签查找更多的资源，那么书签查找就是最佳的选择了。[

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/xiao_hn/archive/2009/06/11/4259628.aspx

①     锁：每条SQL语句

②     隔离：事务

锁

①

并发问题

丢失更新

未确认的读取（脏读）

不一致的分析（非重复读）：多次读取相同的数据（行）不一致（其他用户更改update）

幻像读：多次读取有不存在和新增的数据（其他用户插入insert或删除delete）

隔离级别

提交读

假设存在表A，如下所示

打开查询分析器并打开两个连接，分别输入如下两个事务：

--事务Ⅰ

SET TRANSACTION ISOLATION LEVEL READ Committed

begin tran

update A set A2 = 20 where A1 = 11

waitfor delay '00:00:10'

rollback tran

--事务Ⅱ

SET TRANSACTION ISOLATION LEVEL READ Committed

select * from A where A1 = 11

如果先运行事务Ⅰ，然后紧接着运行事务Ⅱ，则事务Ⅱ要等待10秒钟（一个连接在修改数据块时别的连接也不能查询这个数据块，直到解锁。反之亦然：读的时候不能写和修改）。

如果把事务Ⅱ改为如下

SET TRANSACTION ISOLATION LEVEL READ UNCommitted

select * from A where A1 = 11

那么事务Ⅱ不需等待，立即执行（可以看出READ UNCommitted事务select不对数据发出共享锁）

• 资源 级别 描述
• RID 行锁 表中的单个行
• Key 行级锁 索引中的行
• Page 页级锁 一个数据页或者索引页
• Extent 页级锁 一组数据页或者索引页
• Table 表级锁 整个表
• Database 数据库级锁 整个数据库

锁模式 描述
• 共享（S） 用于不更改或不更新数据（只读操作），如SELECT语句
• 更新（U） 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。
• 排它（X） 用于数据修改操作，例如 INSERT、UPDATE或DELETE。确保不会同时对同一资源进行多重更新
• 意向 当 Microsoft SQL Server 数据库引擎获取低级别的锁时，它还将在包含更低级别对象的对象上放置意向锁.例如： 当锁定行或索引键范围时，数据库引擎将在包含行或键的页上放置意向锁。当锁定页时，数据库引擎将在包含页的更高级别的对象上放置意向锁。
  意向锁的类型为：意向共享（IS）、意向排它（IX）以及意向排它共享（SIX）
• 架构 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改（Sch-M）和架构稳定（Sch-S）
• 大容量更新（BU） 向表中大容量复制数据并指定了TABLOCK提示时使用

Java代码

1. begin tran   
2. update titles set title_idid＝title_id  where 1＝2  
3. if (selectavg(price)fromtitles)>$15  
4. begin   
5. update titles set price＝price*1.10  
6. where price<(select avg(price)from titles)   
7. end   
8. commit tran  

begin tran
update titles set title_idid＝title_id  where 1＝2
if (selectavg(price)fromtitles)>$15
begin
update titles set price＝price*1.10
where price<(select avg(price)from titles)
end
commit tran

Java代码

1. SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED   
2. SELECT * FROM table1 ROWLOCK WHERE A = 'a1'  

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
SELECT * FROM table1 ROWLOCK WHERE A = 'a1'

Java代码

1. create table table1(A varchar(50)  not  null, B varchar(50) ,C varchar(50));   
2. create table table2(D varchar(50),E varchar(50))   
3. insert table1 (A,B,C) values(‘a1’,’b1’,’c1’);   
4. insert table1 (A,B,C) values(‘a2’,’b2’,’c2’);   
5. insert table1 (A,B,C) values(‘a3’,’b3’,’c3’);   
6. insert table2 (D,E) values(‘d1’,’e1’);   
7. insert table2 (D,E) values(‘d2’,’e2’);  

create table table1(A varchar(50)  not  null, B varchar(50) ,C varchar(50));
create table table2(D varchar(50),E varchar(50))
insert table1 (A,B,C) values(‘a1’,’b1’,’c1’);
insert table1 (A,B,C) values(‘a2’,’b2’,’c2’);
insert table1 (A,B,C) values(‘a3’,’b3’,’c3’);
insert table2 (D,E) values(‘d1’,’e1’);
insert table2 (D,E) values(‘d2’,’e2’);

Java代码

1. -- A事务先更新table1表，在更新时，对其他事务进行排他   
2. begin tran   
3. update table1 set A='aa' where B='b2'；   
4. waitfor delay '00:00:30'； --等待30秒   
5. commit tran   
6. -- A事务先更新table2表   
7. begin tran   
8. select * from table1 where B='b2';   
9. commit tran  

-- A事务先更新table1表，在更新时，对其他事务进行排他
begin tran
update table1 set A='aa' where B='b2'；
waitfor delay '00:00:30'； --等待30秒
commit tran
-- A事务先更新table2表
begin tran
select * from table1 where B='b2';
commit tran

Java代码

1. -- A事务先查询table1表，在查询时，加共享锁，防止其他事务对该表进行修改操作   
2. begin tran   
3. select * from table1 holdlock where B='b2' ;   
4.  -holdlock人为加锁   
5. waitfor delay '00:00:30';--等待30秒   
6. commit tran   
7. -- A事务先查询table1表，后更改table1表   
8. begin tran   
9. select A,C from table1 where B='b2';   
10. update table1 set A='aa' where B='b2';   
11. commit tran  

-- A事务先查询table1表，在查询时，加共享锁，防止其他事务对该表进行修改操作
begin tran
select * from table1 holdlock where B='b2' ;
-holdlock人为加锁
waitfor delay '00:00:30';--等待30秒
commit tran
-- A事务先查询table1表，后更改table1表
begin tran
select A,C from table1 where B='b2';
update table1 set A='aa' where B='b2';
commit tran

Java代码

1. -- A事务先更新table1表，然后延时30秒，再更新table2表；   
2. begin tran   
3. update table1 set A='aa' where B='b2';   
4. --这将在 Table1 中生成排他行锁，直到事务完成后才会释放该锁。   
5. waitfor delay '00:00:30';   
6. --进入延时   
7. update table2 set D='d5' where E='e1' ;   
8. commit tran   
9. -- B事务先更新table2表，然后延时10秒，再更新table1表；   
10. begin tran   
11. update table2 set D='d5' where E='e1';   
12. --这将在 Table2 中生成排他行锁，直到事务完成后才会释放该锁   
13. waitfor delay '00:00:10'  
14. --进入延时   
15. update table1 set A='aa' where B='b2' ;   
16. commit tran  

-- A事务先更新table1表，然后延时30秒，再更新table2表；
begin tran
update table1 set A='aa' where B='b2';
--这将在 Table1 中生成排他行锁，直到事务完成后才会释放该锁。
waitfor delay '00:00:30';
--进入延时
update table2 set D='d5' where E='e1' ;
commit tran
-- B事务先更新table2表，然后延时10秒，再更新table1表；
begin tran
update table2 set D='d5' where E='e1';
--这将在 Table2 中生成排他行锁，直到事务完成后才会释放该锁
waitfor delay '00:00:10'
--进入延时
update table1 set A='aa' where B='b2' ;
commit tran

/* 建立测试表:Card,代表一个真实的卡库,供用户注册.用户要从里边选出一个未使用的卡，也就是F_Flag=0的卡，给用户注册：更新F_Name,F_Time,F_Flag字段. 假如出现两个用户同时更新一张卡的情况，是不能容忍的，也就是我们所说的数据不一致行。*/

create table Card(F_CardNO varchar(20),F_Name varchar(20),F_Flag bit,F_Time datetime)
Go
insert Card(F_CardNo,F_Flag) select '1111-1111',0
insert Card(F_CardNo,F_Flag) select '1111-1112',0
insert Card(F_CardNo,F_Flag) select '1111-1113',0
insert Card(F_CardNo,F_Flag) select '1111-1114',0
insert Card(F_CardNo,F_Flag) select '1111-1115',0
insert Card(F_CardNo,F_Flag) select '1111-1116',0
insert Card(F_CardNo,F_Flag) select '1111-1117',0
insert Card(F_CardNo,F_Flag) select '1111-1118',0
insert Card(F_CardNo,F_Flag) select '1111-1119',0
insert Card(F_CardNo,F_Flag) select '1111-1110',0
Go

-- 下边是我们经常使用的更新方案如下:

declare @CardNo varchar(20)
Begin Tran

-- 选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card where F_Flag=0

-- 延迟50秒，模拟并发访问.
waitfor delay '000:00:50'

-- 把刚才选择出来的卡进行注册.

update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNo

commit

问题:假如我们在同一窗口执行同一段代码，但是去掉了waitfor delay子句.两边执行完毕后 我们发现尽管执行了两次注册，但是只注册了一张卡，也就是两个人注册了同一张卡.

悲观锁定解决方案

-- 我们只要对上边的代码做微小的改变就可以实现悲观的锁定.

declare @CardNo varchar(20)
Begin Tran

-- 选择一张未使用的卡
select top 1 @CardNo=F_CardNo
from Card with (UPDLOCK) where F_Flag=0

-- 延迟50秒，模拟并发访问.
waitfor delay '000:00:50'

-- 把刚才选择出来的卡进行注册.

update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNo

commit

注重其中的区别了吗?with(updlock),是的,我们在查询的时候使用了with (UPDLOCK)选项,在查询记录的时候我们就对记录加上了更新锁,表示我们即将对次记录进行更新.注重更新锁和共享锁是不冲突的,也就是其他用户还可以查询此表的内容,但是和更新锁和排它锁是冲突的.所以其他的更新用户就会阻塞.假如我们在另外一个窗口执行此代码,同样不加waifor delay子句.两边执行完毕后,我们发现成功的注册了两张卡.可能我们已经发现了悲观锁定的缺点:当一个用户进行更新的事务的时候,其他更新用户必须排队等待,即使那个用户更新的不是同一条记录.

乐观锁定解决方案

-- 首先我们在Card表里边加上一列F_TimeStamp 列,该列是varbinary(8)类型.但是在更新的时候这个值会自动增长.

alter table Card add F_TimeStamp timestamp not null

-- 悲观锁定
declare @CardNo varchar(20)
declare @timestamp varbinary(8)
declare @rowcount int

Begin Tran

-- 取得卡号和原始的时间戳值
select top 1 @CardNo=F_CardNo,
@timestamp=F_TimeStamp
from Card
where F_Flag=0

-- 延迟50秒，模拟并发访问.
waitfor delay '000:00:50'

-- 注册卡,但是要比较时间戳是否发生了变化.假如没有发生变化.更新成功.假如发生变化,更新失败.

update Card
set F_Name=user,
F_Time=getdate(),
F_Flag=1
where F_CardNo=@CardNo and F_TimeStamp=@timestamp
set @rowcount=@@rowcount
if @rowcount=1
begin
print '更新成功!'
commit
end
else if @rowcount=0
begin
if exists(select 1 from Card where F_CardNo=@CardNo)
begin
print '此卡已经被另外一个用户注册！'
rollback tran
end
else
begin
print '并不存在此卡!'
rollback tran
end
end

在另外一个窗口里边执行没有waitfor的代码,注册成功后,返回原来的窗口,我们就会发现到时间后它显示的提示是此卡以被另外一个用户注册的提示.很明显,这样我们也可以避免两个用户同时注册一张卡的现象的出现.同时,使用这种方法的另外一个好处是没有使用更新锁,这样增加的系统的并发处理能力.

上边我具体介绍了乐观锁定和悲观锁定的使用方法,在实际生产环境里边,假如并发量不大,我们完全可以使用悲观锁定的方法,因为这种方法使用起来非常方便和简单.但是假如系统的并发非常大的话,悲观锁定会带来非常大的性能问题,所以我们就要选择乐观锁定的方法.

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gudenren/archive/2009/07/31/4397291.aspx

何谓“持久层”
持久层（Persistence Layer），即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。

何谓“对象数据映射（ORM）”
ORM-Object/Relational Mapper，即“对象-关系型数据映射组件”。对于O/R，即 Object（对象）和 Relational（关系型数据），表示必须同时使用面向对象和关系型数据进行开发。

备注：建模领域中的 ORM 为 Object/Role Modeling（对象角色建模）。另外这里是“O/R Mapper”而非“O/R Mapping”。相对来讲，O/R Mapping 描述的是一种设计思想或者实现机制，而 O/R Mapper指以O/R原理设计的持久化框架（Framework），包括 O/R机制还有 SQL自生成，事务处理，Cache管理等。

除了 ORM 技术，还有以下几种持久化技术

主动域对象模式
它是在实现中封装了关系数据模型和数据访问细节的一种形式。在 J2EE 架构中，EJB 组件分为会话 EJB 和实体 EJB。会话 EJB 通常实现业务逻辑，而实体 EJB 表示业务实体。实体 EJB 又分为两种：由 EJB 本身管理持久化，即 BMP（Bean-Managed Persistence）；有 EJB 容器管理持久化，即 CMP（Container-Managed Persistence）。BM P就是主动域对象模式的一个例子，BMP 表示由实体 EJB 自身管理数据访问细节。
主动域对象本身位于业务逻辑层，因此采用主动域对象模式时，整个应用仍然是三层应用结构，并没有从业务逻辑层分离出独立的持久化层。

JDO 模式
Java Data Objects（JDO）是 SUN 公司制定的描述对象持久化语义的标准API。严格的说，JDO 并不是对象-关系映射接口，因为它支持把对象持久化到任意一种存储系统中，包括 关系数据库、面向对象的数据库、基于 XML 的数据库，以及其他专有存储系统。由于关系数据库是目前最流行的存储系统，许多 JDO 的实现都包含了对象-关系映射服务。

CMP 模式
在 J2EE 架构中，CMP（Container-Managed Persistence）表示由 EJB 容器来管理实体 EJB 的持久化，EJB 容器封装了对象-关系的映射及数据访问细节。CMP 和 ORM 的相似之处在于，两者都提供对象-关系映射服务，都把对象持久化的任务从业务逻辑中分离出来。区别在于 CMP 负责持久化实体 EJB 组件，而 ORM 负责持久化 POJO，它是普通的基于 Java Bean 形式的实体域对象。

一般把基于 Java Bean 形式的实体域对象称为 POJO（Plain Old Java Object），意为又普通又古老的 Java 对象的意思。随着各种 ORM 映射工具的日趋成熟和流行，POJO有重现光彩，它和基于 CMP 的实体 EJB 相比，即简单又具有很高的可移植性，因此联合使用 ORM 映射工具和 POJO，已经成为一种越来越受欢迎的且用来取代 CMP 的持久化方案。POJO 的缺点就是无法做远程调用，不支持分布式计算。

为什么要做持久化和ORM设计

在目前的企业应用系统设计中，MVC，即 Model（模型）- View（视图）- Control（控制）为主要的系统架构模式。MVC 中的 Model 包含了复杂的业务逻辑和数据逻辑，以及数据存取机制（如 JDBC的连接、SQL生成和Statement创建、还有ResultSet结果集的读取等）等。将这些复杂的业务逻辑和数据逻辑分离，以将系统的紧耦合关系转化为松耦合关系（即解耦合），是降低系统耦合度迫切要做的，也是持久化要做的工作。MVC 模式实现了架构上将表现层（即View）和数据处理层（即Model）分离的解耦合，而持久化的设计则实现了数据处理层内部的业务逻辑和数据逻辑分离的解耦合。而 ORM 作为持久化设计中的最重要也最复杂的技术，也是目前业界热点技术。

简单来说，按通常的系统设计，使用 JDBC 操作数据库，业务处理逻辑和数据存取逻辑是混杂在一起的。
一般基本都是如下几个步骤：
1、建立数据库连接，获得 Connection 对象。
2、根据用户的输入组装查询 SQL 语句。
3、根据 SQL 语句建立 Statement 对象 或者 PreparedStatement 对象。
4、用 Connection 对象执行 SQL语句，获得结果集 ResultSet 对象。
5、然后一条一条读取结果集 ResultSet 对象中的数据。
6、根据读取到的数据，按特定的业务逻辑进行计算。
7、根据计算得到的结果再组装更新 SQL 语句。
8、再使用 Connection 对象执行更新 SQL 语句，以更新数据库中的数据。
7、最后依次关闭各个 Statement 对象和 Connection 对象。

由上可看出代码逻辑非常复杂，这还不包括某条语句执行失败的处理逻辑。其中的业务处理逻辑和数据存取逻辑完全混杂在一块。而一个完整的系统要包含成千上万个这样重复的而又混杂的处理过程，假如要对其中某些业务逻辑或者一些相关联的业务流程做修改，要改动的代码量将不可想象。另一方面，假如要换数据库产品或者运行环境也可能是个不可能完成的任务。而用户的运行环境和要求却千差万别，我们不可能为每一个用户每一种运行环境设计一套一样的系统。
所以就要将一样的处理代码即业务逻辑和可能不一样的处理即数据存取逻辑分离开来，另一方面，关系型数据库中的数据基本都是以一行行的数据进行存取的，而程序运行却是一个个对象进行处理，而目前大部分数据库驱动技术（如ADO.NET、JDBC、ODBC等等）均是以行集的结果集一条条进行处理的。所以为解决这一困难，就出现 ORM 这一个对象和数据之间映射技术。

举例来说，比如要完成一个购物打折促销的程序，用 ORM 思想将如下实现（引自《深入浅出Hibernate》）：
业务逻辑如下：
public Double calcAmount(String customerid, double amount)
{
    // 根据客户ID获得客户记录
    Customer customer = CustomerManager.getCustomer(custmerid);
    // 根据客户等级获得打折规则
    Promotion promotion = PromotionManager.getPromotion(customer.getLevel());
    // 累积客户总消费额，并保存累计结果
    customer.setSumAmount(customer.getSumAmount().add(amount);
    CustomerManager.save(customer);
    // 返回打折后的金额
    return amount.multiply(protomtion.getRatio());
}
这样代码就非常清晰了，而且与数据存取逻辑完全分离。设计业务逻辑代码的时候完全不需要考虑数据库JDBC的那些千篇一律的操作，而将它交给 CustomerManager 和 PromotionManager 两个类去完成。这就是一个简单的 ORM 设计，实际的 ORM 实现框架比这个要复杂的多。

目前有哪些流行的 ORM 产品
目前众多厂商和开源社区都提供了持久层框架的实现，常见的有
Apache OJB （http://db.apache.org/ojb/）
Cayenne （http://objectstyle.org/cayenne/）
Jaxor （http://jaxor.sourceforge.net）
Hibernate （http://www.hibernate.org）
iBatis （http://www.ibatis.com）
jRelationalFramework （http://ijf.sourceforge.net）
mirage （http://itor.cq2.org/en/oss/mirage/toon）
SMYLE （http://www.drjava.de/smyle）
TopLink （http://otn.oracle.com/products/ias/toplink/index.html）
其中 TopLink 是 Oracle 的商业产品，其他均为开源项目。

其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位，甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准，这也是开源项目影响工业领域标准的有力见证。

    对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的,面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。

    面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。

    让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库。在业务逻辑层和用户界面层中，我们是面向对象的。当对象信息发生变化的时候，我们需要把对象的信息保存在关系数据库中。

    当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码，用来从数据库保存，删除，读取对象信息，等等。你在DAL中写了很多的方法来读取对象数据，改变状态对象等等任务。而这些代码写起来总是重复的。

　　如果打开你最近的程序，看看DAL代码，你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例，你传入一个对象，为SqlCommand对象添加SqlParameter，把所有属性和对象对应，设置SqlCommand的CommandText属性为存储过程，然后运行SqlCommand。对于每个对象都要重复的写这些代码。

　　除此之外，还有更好的办法吗？有，引入一个O/R Mapping。实质上，一个O/R Mapping会为你生成DAL。与其自己写DAL代码，不如用O/R Mapping。你用O/R Mapping保存，删除，读取对象，O/R Mapping负责生成SQL，你只需要关心对象就好。

一般的ORM包括以下四部分：

u          一个对持久类对象进行CRUD操作的API；

u          一个语言或API用来规定与类和类属性相关的查询；

u          一个规定mapping metadata的工具；

u          一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。

事例

极致业务基础平台采用ORM技术实现数据的持久化,并提供了完整的实体定义工具,元数据管理机制,自动生成关系数据库表结构.

平台下载地址:

http://www.jeez.com.cn/jbf