博客园_Redsoft

需求分析——你好，我好，大家好！

2010-11-30T02:39:00Z

前言

1、长久以来，在技术人员的映象中“需求分析”就是一个字“改”！

2、除了在要交付文档中会出现“需求分析”，其他地方你想再见它，比你遇到初恋情人还要难。

3、技术人员对此表示情绪稳定。

1、为什么要做需求分析

需求分析简单的说是弄清楚我们到底要“做什么”，在过去的软件工程历史中，很久一段时间认为需求分析是软件工程中最简单的一个步骤，但无数的经验告诉人们需求分析是软件工程最关键的一环，因此大家开始重新认识需求分析。要弄清楚“做什么”，其实并不容易，它涉及沟通、理解、抽象以及专业方面的能力。但往往不是这些困难阻碍我们不去做需求分析，我们不做需求分析的原因大致包括：

1、认为做需求分析花费时间，希望把更多时间投入开发；

2、做不做需求分析貌似对项目影响不是很大，“需求分析”只需要在文档中出现；

3、大家已经习惯用“边做边改模型（Build-and-Fix Model）”进行开发，没有习惯去做需求分析，同时也没有培养这方面的专业人员。

我们抱着以上这些原因在软件行业走了这么多年，并且表示没有压力，我们做网站就是模仿，做项目就是搞懂客户的主要意图，然后围绕这个“意图”，反复存取数据库。我们没有去研究客户的详细需求，我们认为“客户也说不清楚需求”，“客户不懂技术”，我们一次又一次的先入为主去构造自己希望的软件模样，然后一次又一次的返工，回过头才发现时间已经过了项目交付的日期，但还有很地方要改。似乎我们对此已经习惯，但这种“习惯”并不是好事，可能我们有办法让项目延期，让项目不完全满足客户需求，但最终受长远影响的是自己，我们会慢慢降低对自己的要求，我们没有执行专业的软件开发流程，我的软件质量逐渐下降，操作不够人性化，我们缺乏甚至没有意识去做需求分析，而这些都在时时刻刻发生着，但其实我们完全可以做的更好……

2、怎么做好需求分析

（1）调查你的客户情况

调查你的客户属于的客户群体，是政府还是企业还是特殊行业工作者，分析他们的职业特征和计算机操作能力，研究他们想得到什么，他们想到的甚至他们没有想到的，你都要分析到。

（2）确认客户对项目的需求

分析完了客户的需求，你需要对这些需求向客户确认，进一步得到更准确的信息，以及客户对你的需求分析成果的态度，这利于在项目进行中把握客户的心态进行变更控制。

（3）根据需求分析，详细说明项目边界，制定相关的设计文档

需求分析不只是出现在文档中，它还需要执行，需求分析的成果会作为输入来支撑详细设计，也就是说详细设计是否清楚，是否准确与需求分析息息相关，我们不只一次的让技术人员做详细设计，让技术人员编写各类文档，技术人员成为了全能人才，在不经意之间他已经扮演了半个项目经理的角色，这就是我们现在存在的一个问题“分工不合理，职责不明确”，而这些都归根于没有做合理的软件开发流程，没有严格的执行需求分析，因为没有需求分析，我们的需求往往在项目开发出来才知道。

3、两个矛盾点

（1）、分析人员与客户之间

客户往往是不懂技术的，甚至不了解计算机应用，他们阐述的需求是最实在的，他们说的很简单，就是“我让做到……”，“我这样做就可以……”，但这最实在话在分析人员眼里却是最抽象的，因为他不能在需求分析中写“客户要怎么做？”“客户在什么地方需要……”，分析人员要抽象要归纳，在这抽象和归纳的过程就就可能出现误差，或者等分析人员归纳完毕，客户新的需求又打破了原本的抽象归纳的成果，再者客户也不知道他的全部要求，等你提醒他，他才想起，这个功能确实好，加进去。所以分析人员与客户之间存在一个矛盾，这个矛盾就是“需求”在他们脑子中的形象往往不是对等的。

（2）、分析人员与技术人员

技术人员的职责是什么，在组织结构不完整，职责不明确的公司里，技术人员是需求分析者，是美工，是程序员，是文档编写者甚至是电脑维修员。在组织结构完整，分工明确，生产高效的公司里，技术人员是台高速运转的机器，你给他指令，他给你结果。我们常常遇到这么一个情景，技术人员抱怨客户的需求过分，因为今天说这样做，他明天说要那样做，技术人员很痛苦。但这原因是什么？是我们的分析人员没有和技术人员进行良好的沟通，没有把客户的需求准确的变为详细设计，而是告诉技术人员一个要求——要这样。所以技术人员就开始自由发挥，发挥的结果就是客户不接受。如果给他一个详细设计（这前提当然是要需求分析），他发挥的余地仅限于他的专业技术，那么结果会很理想。所以分析人员（往往是项目经理）与技术人员之间也存在一个矛盾，这个矛盾就是分析人员和技术人员对“需求”的理解精度不同。

其实解决以上两个矛盾点，破解之处就是需求分析，只要做好需求分析，我们可以交给客户满意的产品，让开发更有效率，每个人都知道自己的责任在哪里，自己的重点放在哪里，这样就你好，我好，大家好！

前面的路很长，我们都在不断进步，每一天我们的生活都充满激情，我们喜爱自己的工作，并从中感到无穷的乐趣！

本文链接

PHP问题列表(持续更新)

2010-11-30T02:21:00Z

1、安装

环境：windows xp+Apache HTTP Server (httpd) 2.2.15+php5.3

(1)、windows xp安装略。

(2)、Apache HTTP Server (httpd) 2.2.15，下载地址：http://httpd.apache.org/download.cgi 。我下载的是：Win32 Binary including OpenSSL 0.9.8m (MSI Installer): httpd-2.2.15-win32-x86-openssl-0.9.8m-r2.msi。安装成功之后，启动。在浏览器地址栏：敲入localhost:8080(你的端口)，一切正常的话，会出现一下页面：

如遇到问题可参阅：http://blog.sina.com.cn/s/blog_53f716d40100hvd9.html

(3)、PHP5.3，下载地址：http://www.php.net/downloads.php。这里注意一下，如果你在windows系统下部署，请选择http://windows.php.net/download/。特别注意的地方：这里有VC9 x86 Non Thread Safe、VC9 x86 Thread Safe、VC6 x86 Non Thread Safe、VC6 x86 Thread Safe等版本。

怎么选择它们：

Non Thread Safe：无线程安全的（这个版本下找不到php5apache2.dll以及php5apache2_2.dll）；

Thread Safe：线路安全的，一般apache模块、iis的ISAPI需要使用（所以应该选择它）；

VC6：这是给Apache用的。

VC9:这是给IIS用的。

因为综上，应该选择VC6 x86 Thread Safe这个版本，下载地址：http://windows.php.net/downloads/releases/php-5.3.2-Win32-VC6-x86.zip，你也可以选择安装版：http://windows.php.net/downloads/releases/php-5.3.2-Win32-VC6-x86.msi。安装PHP，可参阅：http://blog.sina.com.cn/s/blog_53f716d40100hvd9.html。编写一个PHP页面，放在Apache-HTTP-Server\htdocs测试一下：

PHP页面内容：

<?php echo "Some Data"; ?>

如果幸运的话你会看到：

可查阅相关网址得到帮助：

(4)、Apache HTTP Server Version 2.2 文档：http://lamp.linux.gov.cn/Apache/ApacheMenu/

PHP 5.0和Apache HTTP Server 2.0 整合记录：http://heavyz.sourceforge.net/homepage/homepage_zh/comp/notes/php-5.0.html

待续……

本文链接

[收藏]mysql 性能的检查和调优方法

2010-04-02T09:23:00Z

来源：http://www.sudone.com/linux/mysql_debug.html
作者：Ayou

我一直是使用mysql这个数据库软件，它工作比较稳定，效率也很高。在遇到严重性能问题时，一般都有这么几种可能：
1、索引没有建好；
2、sql写法过于复杂；
3、配置错误；
4、机器实在负荷不了；
1、索引没有建好
如果看到mysql消耗的cpu很大，可以用mysql的client工具来检查。
在linux下执行
/usr/local/mysql/bin/mysql -hlocalhost -uroot -p
输入密码，如果没有密码，则不用-p参数就可以进到客户端界面中。
看看当前的运行情况
show full processlist
可以多运行几次
这个命令可以看到当前正在执行的sql语句，它会告知执行的sql、数据库名、执行的状态、来自的客户端ip、所使用的帐号、运行时间等信息
在我的cache后端，这里面大部分时间是看不到显示任何sql语句的，我认为这样才算比较正常。如果看到有很多sql语句，那么这台mysql就一定会有性能问题
如果出现了性能问题，则可以进行分析：
1、是不是有sql语句卡住了？
这是出现比较多的情况，如果数据库是采用 myisam，那么有可能有一个写入的线程会把数据表给锁定了，如果这条语句不结束，则其它语句也无法运行。
查看processlist 里的time这一项，看看有没有执行时间很长的语句，要留意这些语句。
2、大量相同的sql语句正在执行
如果出现这种情况，则有可能是该sql语句执行的效率低下，同样要留意这些语句。
然后把你所怀疑的语句统统集合一下，用desc（explain）来检查这些语句。
首先看看一个正常的desc输出：
mysql> desc select * from imgs where imgid=1651768337;
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| 1 | SIMPLE      | imgs | const | PRIMARY       | PRIMARY | 8       | const |    1 |       |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)
注意key、rows和Extra这三项，这条语句返回的结果说明了该sql会使用 PRIMARY主键索引来查询，结果集数量为1条，Extra没有显示，证明没有用到排序或其他操作。由此结果可以推断，mysql会从索引中查询 imgid=1651768337这条记录，然后再到真实表中取出所有字段，是很简单的操作。
key是指明当前sql会使用的索引，mysql执行一条简单语句时只能使用到一条索引，注意这个限制；rows是返回的结果集大小，结果集就是使用该索引进行一次搜索的所有匹配结果；Extra一般会显示查询和排序的方式，。
如果没有使用到key，或者rows很大而用到了filesort排序，一般都会影响到效率，例如：
mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra                       |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
| 1 | SIMPLE      | imgs | ALL | NULL          | NULL | NULL    | NULL | 12506 | Using where; Using filesort |
+----+-------------+-------+------+---------------+------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)
这条sql结果集会有12506条，用到了filesort，所以执行起来会非常消耗效率的。这时mysql执行时会把整个表扫描一遍，一条一条去找到匹配userid="7mini"的记录，然后还要对这些记录的clicks进行一次排序，效率可想而知。真实执行时如果发现还比较快的话，那是因为服务器内存还足够将12506条比较短小的记录全部读入内存，所以还比较快，但是并发多起来或者表大起来的话，效率问题就严重了。
这时我把userid加入索引：
create index userid on imgs (userid);
然后再检查：
mysql> desc select * from imgs where userid="7mini" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE      | imgs | ref | userid        | userid | 51      | const |    8 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)
嗯，这时可以看到mysql使用了userid这个索引搜索了，用userid索引一次搜索后，结果集有8条。然后虽然使用了filesort一条一条排序，但是因为结果集只有区区8条，效率问题得以缓解。
但是，如果我用别的 userid查询，结果又会有所不同：
mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE      | imgs | ref | userid        | userid | 51      | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)
这个结果和userid="7mini"的结果基本相同，但是mysql用userid索引一次搜索后结果集的大小达到2944条，这2944条记录都会加入内存进行filesort，效率比起7mini那次来说就差很多了。这时可以有两种办法可以解决，第一种办法是再加一个索引和判断条件，因为我只需要根据点击量取最大的10条数据，所以有很多数据我根本不需要加进来排序，比如点击量小于 10的，这些数据可能占了很大部分。
我对clicks加一个索引，然后加入一个where条件再查询：
create index clicks on imgs(clicks);
mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref   | rows | Extra                       |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
| 1 | SIMPLE      | imgs | ref | userid,clicks | userid | 51      | const | 2944 | Using where; Using filesort |
+----+-------------+-------+------+---------------+--------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)
这时可以看到possible_keys变成了 userid,clicks，possible_keys是可以匹配的所有索引，mysql会从possible_keys中自己判断并取用其中一个索引来执行语句，值得注意的是，mysql取用的这个索引未必是最优化的。这次查询mysql还是使用userid这个索引来查询的，并没有按照我的意愿，所以结果还是没有什么变化。改一下sql加上useindex强制mysql使用clicks索引：
mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>10 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE      | imgs | range | clicks        | clicks | 4       | NULL | 5455 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)
这时mysql用到了clicks索引进行查询，但是结果集比userid还要大！看来还要再进行限制：
mysql> desc select * from imgs use index (clicks) where userid='admin' and clicks>1000 order by clicks desc limit 10
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key    | key_len | ref | rows | Extra       |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE      | imgs | range | clicks        | clicks | 4       | NULL | 312 | Using where |
+----+-------------+-------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)
加到1000的时候结果集变成了312条，排序效率应该是可以接受。
不过，采用换索引这种优化方式需要取一个采样点，比如这个例子中的1000这个数字，这样，对userid的每个数值，都要去找一个采样点，这样对程序来说是很难办的。如果按1000取样的话，那么userid='7mini'这个例子中，取到的结果将不会是8条，而是2条，给用户造成了困惑。
当然还有另一种办法，加入双索引：
create index userid_clicks on imgs (userid, clicks)
mysql> desc select * from imgs where userid="admin" order by clicks desc limit 10;
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys        | key           | key_len | ref   | rows | Extra       |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
| 1 | SIMPLE      | imgs | ref | userid,userid_clicks | userid_clicks | 51      | const | 2944 | Using where |
+----+-------------+-------+------+----------------------+---------------+---------+-------+------+-------------+
1 row in set (0.00 sec)
这时可以看到，结果集还是2944条，但是Extra中的filesort不见了。这时 mysql使用userid_clicks这个索引去查询，这不但能快速查询到userid="admin"的所有记录，并且结果是根据clicks排好序的！所以不用再把这个结果集读入内存一条一条排序了，效率上会高很多。
但是用多字段索引这种方式有个问题，如果查询的sql种类很多的话，就得好好规划一下了，否则索引会建得非常多，不但会影响到数据insert和update的效率，而且数据表也容易损坏。
以上是对索引优化的办法，因为原因可能会比较复杂，所以写得比较的长，一般好好优化了索引之后，mysql的效率会提升n个档次，从而也不需要考虑增加机器来解决问题了。
但是，mysql甚至所有数据库，可能都不好解决limit的问题。在mysql中，limit 0,10只要索引合适，是没有问题的，但是limit100000,10就会很慢了，因为mysql会扫描排好序的结果，然后找到100000这个点，取出10条返回。要找到100000这个点，就要扫描100000条记录，这个循环是比较耗时的。不知道会不会有什么好的算法可以优化这个扫描引擎，我冥思苦想也想不出有什么好办法。对于limit，目前直至比较久远的将来，我想只能通过业务、程序和数据表的规划来优化，我想到的这些优化办法也都还没有一个是万全之策，往后再讨论。
2、sql写法过于复杂
sql写法假如用到一些特殊的功能，比如groupby、或者多表联合查询的话，mysql用到什么方式来查询也可以用desc来分析，我这边用复杂sql的情况还不算多，所以不常分析，暂时就没有好的建议。
3、配置错误
配置里主要参数是key_buffer、sort_buffer_size/myisam_sort_buffer_size，这两个参数意思是：
key_buffer=128M：全部表的索引都会尽可能放在这块内存区域内，索引比较大的话就开稍大点都可以，我一般设为128M，有个好的建议是把很少用到并且比较大的表想办法移到别的地方去，这样可以显著减少mysql的内存占用。
sort_buffer_size=1M：单个线程使用的用于排序的内存，查询结果集都会放进这内存里，如果比较小，mysql会多放几次，所以稍微开大一点就可以了，重要是优化好索引和查询语句，让他们不要生成太大的结果集。
另外一些配置：
thread_concurrency=8：这个配置标配=cpu数量x2
interactive_timeout=30
wait_timeout=30：这两个配置使用10-30秒就可以了，这样会尽快地释放内存资源，注意：一直在使用的连接是不会断掉的，这个配置只是断掉了长时间不动的连接。
query_cache：这个功能不要使用，现在很多人看到cache这几个字母就像看到了宝贝，这是不唯物主义的。mysql的query_cache在每次表数据有变化的时候都会重新清理连至该表的所有缓存，如果更新比较频繁，query_cache不但帮不上忙，而且还会对效率影响很大。这个参数只适合只读型的数据库，如果非要用，也只能用query_cache_type=2自行用SQL_CACHE指定一些sql进行缓存。
max_connections：默认为100，一般情况下是足够用的，但是一般要开大一点，开到400-600就可以了，能超过600的话一般就有效率问题，得另找对策，光靠增加这个数字不是办法。
其它配置可以按默认就可以了，个人觉得问题还不是那么的大，提醒一下：1、配置虽然很重要，但是在绝大部分情况下都不是效率问题的罪魁祸首。2、mysql是一个数据库，对于数据库最重要考究的不应是效率，而是稳定性和数据准确性。
4、机器实在负荷不了
如果做了以上调整，服务器还是不能承受，那就只能通过架构级调整来优化了。
1、mysql同步。
通过mysql同步功能将数据同步到数台从数据库，由主数据库写入，从数据库提供读取。
我个人不是那么乐意使用mysql同步，因为这个办法会增加程序的复杂性，并常常会引起数据方面的错误。在高负荷的服务中，死机了还可以快速重启，但数据错误的话要恢复就比较麻烦。
2、加入缓存
加入缓存之后，就可以解决并发的问题，效果很明显。如果是实时系统，可以考虑用刷新缓存方式使缓存保持最新。
在前端加入squid的架构比较提倡使用，在命中率比较高的应用中，基本上可以解决问题。
如果是在程序逻辑层里面进行缓存，会增加很多复杂性，问题会比较多而且难解决，不建议在这一层面进行调整。
3、程序架构调整，支持同时连接多个数据库
如果web加入缓存后问题还是比较严重，只能通过程序架构调整，把应用拆散，用多台的机器同时提供服务。
如果拆散的话，对业务是有少许影响，如果业务当中有部分功能必须使用所有的数据，可以用一个完整库+n个分散库这样的架构，每次修改都在完整库和分散库各操作一次，或定期整理完整库。
当然，还有一种最笨的，把数据库整个完完整整的做拷贝，然后程序每次都把完整的sql在这些库执行一遍，访问时轮询访问，我认为这样要比mysql同步的方式安全。
4、使用 mysql proxy 代理
mysql proxy 可以通过代理把数据库中的各个表分散到数台服务器，但是它的问题是没有能解决热门表的问题，如果热门内容散在多个表中，用这个办法是比较轻松就能解决问题。
我没有用过这个软件也没有认真查过，不过我对它的功能有一点点怀疑，就是它怎么实现多个表之间的联合查询？如果能实现，那么效率如何呢？
5、使用memcachedb
数据库换用支持mysql的memcachedb，是可以一试的想法，从 memcachedb的实现方式和层面来看对数据没有什么影响，不会对用户有什么困扰。
为我现在因为数据库方面问题不多，没有试验过这个玩意。不过，只要它支持mysql的大部分主要的语法，而且本身稳定，可用性是无需置疑的。

本文链接

【收藏】hibernate 集合映射inverse和cascade详解

2010-04-02T08:41:00Z

１、到底在哪用cascade="..."？

cascade属性并不是多对多关系一定要用的，有了它只是让我们在插入或删除对像时更方便一些，只要在 cascade的源头上插入或是删除，所有cascade的关系就会被自己动的插入或是删除。便是为了能正确的cascade，unsaved- value是个很重要的属性。Hibernate通过这个属性来判断一个对象应该save还是update，如果这个对象的id是unsaved- value的话，那说明这个对象不是persistence object要save（insert)；如果id是非unsaved-value的话，那说明这个对象是persistence object（数据库中已存在），只要update就行了。saveOrUpdate方法用的也是这个机制。

２、到底在哪用inverse="ture"?

inverse属性默认是false的，就是说关系的两端都来维护关系。这个意思就是说，如有一个Student, Teacher和TeacherStudent表，Student和Teacher是多对多对多关系，这个关系由TeacherStudent这个表来表现。那么什么时候插入或删除TeacherStudent表中的记录来维护关系呢？在用hibernate时，我们不会显示的对 TeacherStudent表做操作。对TeacherStudent的操作是hibernate帮我们做的。hibernate就是看hbm文件中指定的是"谁"维护关系，那个在插入或删除"谁"时，就会处发对关系表的操作。前提是"谁"这个对象已经知道这个关系了，就是说关系另一头的对象已经set 或是add到"谁"这个对象里来了。前面说过inverse默认是false，就是关系的两端都维护关系，对其中任一个操作都会处发对表系表的操作。当在关系的一头，如Student中的bag或set中用了inverse＝"true"时，那就代表关系是由另一关维护的（Teacher）。就是说当这插入Student时，不会操作TeacherStudent表，即使Student已经知道了关系。只有当Teacher插入或删除时才会处发对关系表的操作。所以，当关系的两头都用inverse="true"是不对的，就会导致任何操作都不处发对关系表的操作。当两端都是 inverse="false"或是default值是，在代码对关系显示的维护也是不对的，会导致在关系表中插入两次关系。

在一对多关系中inverse就更有意义了。在多对多中，在哪端inverse="true"效果差不多（在效率上）。但是在一对多中，如果要一方维护关系，就会使在插入或是删除"一"方时去update"多"方的每一个与这个"一"的对象有关系的对象。而如果让" 多"方面维护关系时就不会有update操作，因为关系就是在多方的对象中的，直指插入或是删除多方对象就行了。当然这时也要遍历"多"方的每一个对象显示的操作修关系的变化体现到DB中。不管怎样说，还是让"多"方维护关系更直观一些。

３、cascade和inverse有什么区别？

可以这样理解，cascade定义的是关系两端对象到对象的级联关系；而inverse定义的是关系和对象的级联关系。

all : 所有情况下均进行关联操作。
none：所有情况下均不进行关联操作。这是默认值。
save-update:在执行save/update/saveOrUpdate时进行关联操作。
delete：在执行delete时进行关联操作。

all的意思是save-update + delete
all-delete-orphan 的意思是当对象图中产生孤儿节点时,在数据库中删除该节点
all比较好理解,举个例子说一下all-delete-orphan:
Category与Item是一对多的关系,也就是说Category类中有个Set类型的变量items.
举个例子,现items中存两个Item, item1,item2,如果定义关系为all-delete-orphan
当items中删除掉一个item(比如用remove()方法删除item1),那么被删除的Item类实例
将变成孤儿节点,当执行category.update(),或session.flush()时
hibernate同步缓存和数据库,会把数据库中item1对应的记录删掉

4、hibernate如何根据pojo来更新数据库
4.0 在commit/flush之前，hibernate不会对pojo对象作神秘的处理。
4.0.1 在select查询出pojo时，hibernate根据“字段--属性”的对应关系，用字段的值填充pojo的属性；
然后根据“关系标记”生成sql语句从relationTable中查询出满足条件的relationPojo，并把这些relatinPojo
放到“关系属性”中。这个过程是机械的。
4.0.2 在pojo对象被查出来后，到commit(或flush)之前，它将是一个普通的java对象，hibernate不会做额外的手脚。
比如，不会限制你设置一个属性的值为null或其它任何值
在集合类Set的add(object)操作时，不会改变object的值，不会检查参数object是否是一个pojo对象
设置mainPojo的一个“桥属性”的值，不会自动设置relationPojo的对应的“桥属性”的值。
执行session.delete(pojo)时，pojo本身没有变化，他的属性值也没有变化。
执行session.save(pojo)时，如果pojo的id不是hibernate或数据库生成,则它的值没有变化。
如果pojo的id是hibernate或数据库生成，则hibernate会把id给pojo设上去。
extend: 对lazy=true的set，hibernate在进行set的操作(调用java.util.Set中声明的方法)时
会先inialize这个set，仅此而已。而inialize仅仅是从数据库中捞出set的数据。
如果一个set已经被inialize了，那么对它进行的操作就是java.util.Set接口中定义的语义。
另外，如果id由hibernate来生成，那么在save(pojo)时，hibernate会改变该pojo，会设置它的id，这
可能改变该pojo的hashCode，详细地讨论见帖《》
mapping文件中标记的某些属性及pojo对象的操作会对数据库操作产生影响，这些影响都是在commit时才会起作用。
而在commit前pojo的状态不受它们的影响。
不过，待commit之时，将由hibernate完全掌控，它好像知道pojo对象从创建到commit这中间的所有变化。
4.03. 关联更新
"关系标记"对应的属性是一个pojo或一个pojo的集合，修改“关系属性”的值能会导致更新mainTable表，也可能会更新 relationTable表。
这种更新暂叫“关联更新”。

4.1.inverse属性的作用（假定没有设置cascade属性）
4.1.1 “只有集合标记（set/map/list/array/bag）才有inverse属性”。
————不妨以标记set为例，具体为“一个地区（Address表）的学校（School表）” -- address.schoolSet。
4.1.2 “set的inverse属性决定是否把对set的改动反映到数据库中去。
inverse=false————反映；inverse=true————不反映”
inverse属性默认为false
对<one-to-many>和<many-to-many>子标记，这两条都适用。
不管是对set做什么操作，4.1.2都适用。
4.1.3 当inverse=false时，hibernate如何将对set的改动反映到数据库中：
对set的操作主要有：（1）新增元素 address.getSchoolSet().add(oneSchool);
（2）删除元素 address.getSchoolSet().remove(oneSchool);
（3）删除set address.setSchoolSet(null);
（4）设新set address.setSchoolSet( newSchoolSet);
（5）转移set otherSchoolSet = otherAddress.getSchoolSet();
otherAddress.setSchoolSet(null);
address.setSchoolSet(otherSchoolSet);
（6）改变set中元素的属性的值如果是改变key属性，这会导致异常
如果改变的是普通的属性，则hibernate认为set没有变化（在后面可以看出缘由）。
所以这种情形不予考虑。
改变set后，hibernate对数据库的操作根据是<one-to-many>关系还是<many-to-many>关系而有不同。
对one-to-many，对school set的改动，会改变表SCHOOL中的数据:
#SCHOOL_ID是school表的主键，SCHOOL_ADDRESS是school表中的地址栏位
#表School的外键为SCHOOL_ADDRESS，它对应表Address的主键ADDRESS_ID
（11）insert oneSchool———— sqlInsertRowString:
update SCHOOL set SCHOOL_ADDRESS=? where SCHOOL_ID=?
(仅仅update foreign-key的值。)
（22）delete oneSchool———— sqlDeleteRowString:
update SCHOOL set SCHOOL_ADDRESS=null where SCHOOL_ID=?
（很奇怪，把foreign-key设置为null不知道有什么实际意义？）
（33）delete 属于某一address的所有school ————sqlDeleteString：
update SCHOOL set SCHOOL_ADDRESS=null where SCHOOL_ADDRESS=?
（44）update ————sqlUpdateRowString：""， no need
对many-to-many，对school set的改动，会改变关系表ADDRESS_SCHOOL中的数据:
#“地区————学校”的关系为多对多的关系有点牵强，只是为了方便与上面的one-to-many作比较
#假设有一个关系表ADDRESS_SCHOOL，有两个字段ADDRESS_ID, SCHOOL_ID，
#这两个字段分别对应ADDRESS和SCHOOL两表的key
（11）insert的SQL语句为： insert into ADDRESS_SCHOOL(ADDRESS_ID, SCHOOL_ID)
values(?,?)
（22）delete的SQL语句为： delete from ADDRESS_SCHOOL
where ADDRESS_ID=? AND SCHOOL_ID=?
（33）delete all的SQL语句为： delete from ADDRESS_SCHOOL
where ADDRESS_ID=?
（44）update的sql语句为 ————sqlUpdateRowString：
update ADDRESS_SCHOOL set ADDRESS_ID=?
where ADDRESS_ID=? AND SCHOOL_ID=?
对set的操作(1),hibernate会执行(11)sqlInsertRowString
对set的操作(2),hibernate会执行(22)sqlDeleteRowString
对set的操作(3),hibernate会执行(33)sqlDeleteString
对set的操作(4),老的schoolSet因为没有所属的address,所以被全部delete掉，即先执行 (33)sqlDeleteString
然后新增新的schoolSet,即再执行sqlInsertRowString
对set的操作(5)，实际上就是将set从一个pojo转移到另一pojo：
首先，执行sqlDeleteString，删除掉otherAddress所属的school
然后，执行sqlDeleteString，删除掉address原先的school
最后，执行sqlInsertRowString，将otherSchoolSet新增给address
总结：（1）对one-to-many而言，改变set，会让hibernate执行一系列的update语句，不会delete/insert数据
（2）对many-to-many而言，改变set,只修改关系表的数据，不会影响many-to-many的另一方。
（3）虽然one-to-many和many-to-many的数据库操作不一样，但目的都是一个：维护数据的一致性。执行的sql都
只涉及到“桥字段”，不会考虑或改变其他的字段，所以对set的操作(6)是没有效果地。
extend:对list,可能还会维护index字段。
4.1.4 “inverse与cascade没有什么关系，互无牵扯。”
commit后，这两个属性发挥作用的时机不同，hibernate会根据对pojo对象的改动，及cascade属性的设置，
生成一系列的Action，比如UpdateAction,DeleteAction,InsertAction等，每个Action都有execute 方法以执行对应的sql语句。
待所有这些Action都生成好了后，hibernate再一起执行它们，在执行sql前，inverse属性起作用，
当inverse=true时，不执行sql；当inverse=false时，执行sql。
4.1.5 inverse的默认值为false，所以inverse属性默认会进行“关联更新”。
4.1.6 建议：只对set + many-to-many设置inverse=false，其他的标记不考虑inverse属性。
   糟糕的是，不设置inverse属性时，inverse默认为false。
4.2. 级联（cascade）属性的作用：
4.2.1 只有“关系标记”才有cascade属性：many-to-one，one-to-one ，any,
set(map, bag, idbag, list, array) + one-to-many(many-to-many)
4.2.2 级联指的是当主控方执行操作时，关联对象（被动方）是否同步执行同一操作。
pojo和它的关系属性的关系就是“主控方 -- 被动方”的关系，如果关系属性是一个set，那么被动方就是set中的一个一个元素，。
比如：学校（School）有三个属性：地区(Address),校长（TheMaster）和学生(Set，元素为Student)
执行session.delete(school)时，级联决定是否执行 session.delete(Address),session.delete(theMaster)，
是否对每个aStudent执行session.delete(aStudent)。
extend:这点和inverse属性是有区别的。见4.3.
4.2.3 一个操作因级联cascade可能触发多个关联操作。前一个操作叫“主控操作”，后一个操作叫“关联操作”。
cascade属性的可选值：
all : 所有情况下均进行关联操作。
none：所有情况下均不进行关联操作。这是默认值。
save-update:在执行save/update/saveOrUpdate时进行关联操作。
delete：在执行delete时进行关联操作。
具体执行什么“关联操作”是根据“主控操作”来的：
“主控操作”         “关联操作”
session.saveOrUpdate --> session.saveOrUpdate (执行saveOrUpdate实际上会执行save或者update)
session.save ----> session.saveOrUpdate
session.udpate --> session.saveOrUpdate
session.delete --> session.delete
4.2.4 主控操作和关联操作的先后顺序是“先保存one，再保存many；先删除many，再删除one；先update主控方，再update被动方”
对于one-to-one，当其属性constrained="false"（默认值）时，它可看作one-to-many关系；
   当其属性constrained="true"时，它可看作many-to-one关系；
对many-to-many，它可看作one-to-many。
比如：学校（School）有三个属性：地区(Address),校长（TheMaster，其constrained="false"）和学生 (Set，元素为Student)
当执行session.save(school)时，
实际的执行顺序为：session.save(Address);
session.save(school);
session.save(theMaster);
for( 对每一个student ){
session.save(aStudent);
}
当执行session.delete(school)时，
实际的执行顺序为：session.delete(theMaster);
for( 对每一个student ){
session.delete(aStudent);
}
session.delete(school);
session.delete(Address);
当执行session.update(school)时，
实际的执行顺序为：session.update(school);
session.saveOrUpdate(Address);
session.saveOrUpdate(theMaster);
for( 对每一个student ){
session.saveOrUpdate(aStudent);
}
注意：update操作因级联引发的关联操作为saveOrUpdate操作，而不是update操作。
saveOrUpdate与update的区别是：前者根据操作对象是保存了还是没有保存，而决定执行update还是save
extends: 实际中，删除学校不会删除地区，即地区的cascade一般设为false
另外，many-to-many关系很少设置cascade=true，而是设置inverse=false。这个反映了cascade和inverse 的区别。见4.3
4.2.5 cascade的默认值为false，所以inverse属性默认会进行“关联更新”。
4.2.6 总结：级联（cascade）就是操作一个对象时，对它的属性（其cascade=true）也进行这个操作。

4.3 inverse和cascade的比较
这两个属性本身互不影响，但起的作用有些类似，都能引发对关系表的更新。
4.3.1 inverse只对set+one-to-many(或many-to-many)有效，对many-to-one, one-to-one无效。
cascade对关系标记都有效。
4.3.1 inverse对集合对象整体起作用，cascade对集合对象中的一个一个元素起作用，如果集合为空，那么cascade不会引发关联操作。
比如将集合对象置为null， school.setStudentSet(null)
inverse导致hibernate执行:udpate STUDENT set SCHOOL_ID=null where SCHOOL_ID=?
cascade则不会执行对STUDENT表的关联更新，因为集合中没有元素。
再比新增一个school, session.save(school)
inverse导致hibernate执行：
for( 对(school的每一个student ){
udpate STUDENT set SCHOOL_ID=? where STUDENT_ID=? //将学生的school_id改为新的school的id
}
cascade导致hibernate执行：
for( 对school的每一个student ){
session.save(aStudent); //对学生执行save操作
}
extends:如果改变集合中的部分元素（比如新增一个元素），
inverse: hibernate先判断哪些元素改变了，对改变的元素执行相应的sql
cascade: 它总是对集合中的每个元素执行关联操作。
（在关联操作中，hibernate会判断操作的对象是否改变）
4.3.2 两个起作用的时机不同：
cascade：在对主控方操作时，级联发生。
inverse: 在flush时（commit会自动执行flush)，对session中的所有set，hibernate判断每个set是否有变化，
对有变化的set执行相应的sql，执行之前，会有个判断：if( inverse == true ) return;
可以看出cascade在先，inverse在后。
4.3.3 inverse 对set + one-to-many 和 set + many-to-many 起的作用不同。hibernate生成的sql不同。
对one-to-many，hibernate对many方的数据库表执行update语句。
对many-to-many, hibernate对关系表执行insert/update/delte语句，注意不是对many方的数据库表而是关系表。
cascase 对set都是一致的，不管one-to-many还是many-to-many。都简单地把操作传递到set中的每个元素。所以它总是更新many
方的数据库表。
4.3.4 建议：只对set + many-to-many设置inverse=false，其他的标记不考虑inverse属性，都设为inverse=true。
对cascade，一般对many-to-one，many-to-many，constrained=true的one-to-one 不设置级联删除。

本文链接

个人网站开通。

2009-08-30T07:03:00Z

昨天终于把个站开通了，域名加空间一共花了73个大洋，以后争取没事的时候做点东西来放着，呜哈哈，刚才看一个哥们也开了个站放在首页，我想还是低调点。我等以后上面东西多了，再介绍给别人吧。。。。哇哈哈

【原】轻量级的数据交换格式——初识Json(下)

2009-08-24T07:41:00Z

其实第一次见到服务器端使用json是在用asp.net mvc做项目的时候，在asp.net mvc 1.0中Controller可以直接返回给视图一个json对象。但当时大部分时候是返回一个ViewData，对json没有使用过。下面就介绍在.net环境下解析json的一个api——json.net。我们使用Json.net来实现JSON数据的序列化和反序列化。下载地址：http://www....

【原】轻量级的数据交换格式——初识Json(上)

2009-08-18T14:25:00Z

序： 1、两个月前，你从来没有听说过JSON的。 2、一个月前，你听说这一词，但不重视。 3、一周前，你听说它的性能提到了几倍，并开始觉得，有义务去学习下。 4、今天你醒来了，心血来潮，对着JSON说 : 我来了。 ——摘自CssRain json官网 ——http://www.json.org/json-zh.html json.js——http://www.json.org/json.js...

【原】初学Jquery

2009-08-07T07:14:00Z

知道Jquery已经很长时间了，但从来没有应用过，今天打算学习一些简单的功能以及在日常项目中经常使用的效果。官方网站：http://jquery.com/ 下载地址：http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.3.2.min.js&downloadBtn= 其宗旨是——WRITE LESS,DO MOR...

【原】初学Flex之简单图片查看器

2009-08-04T13:09:00Z

我发现写博客是一件挺有意思的事情，我也喜欢我写的大家来看，并一起谈论，我之前写的一个短文，我现在常常去看有没人给我留言，嘿嘿，我好瓜哦。最近也在学习Flex，安装了软件才发现它是基于eclipse的，杂一看界面如此像，看了一些相关的资料，谈谈我的感想： 1、以我不到半年的WPF经验，我觉得WPF和Flex是如此的像，这让我想象微软好多东西都很像别人的（比如asp.net mvc）。flex里面有个...

【原】基于asp.net的Web开发架构探索

2009-08-04T10:20:00Z

问题由来最近在研究适合团队开发的web架构解决方案，该架构即要适合分工协作又要有一定扩展性，适合不同的数据库需要，因此我查阅了一些资料，初步构想出了一套架构，请各位多多指教。探索 web开发架构最经典莫过于三层架构，表示层、逻辑层、数据处理层。数据访问层：其功能主要是负责数据库的访问。业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。表示层：是系统的UI部分，负责使用者...