shenxian

compc -include-file myStule.css -include-file Bg.jpg -o myStyle.swc

cd C:\Example_3\src

转自http://zphab.blog.163.com/blog/static/441387132008627113222268/

备注：有些观点我不认同，例如第三条，如果第三条存在，则表示开发人员没有管理好，比如命名规范。

第一、二、三条作者的分析不认同，应该视情况和环境而定。

----

      1. 数据库移植不方便:

       2. 大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计，无法采用面向对象的方式将业务逻辑进行封装，从而无法形成通用的可支持复用的业务逻辑框架。

       3. 代码可读性差,相当难维护,

       4. 不支持群集 
              金融和电信行业的确在数据库服务器的硬件投资少不会吝惜，但是数据库服务器是单点的，极难扩展，即便Oracle的群集，他的共享存储数据库也是单点的，如果业务逻辑的运算非常消耗CPU和IO，你没有任何有效的办法来扩展系统的性能。

       5. 对于并非极度依赖数据的业务逻辑运算，如果在应用服务器端来实现的话，特别是采用SNA架构的情况下，理论上可以获得无限的水平扩展能力，只要加服务器就行了。但如果你放在数据库里面，你就大眼瞪小眼了，加服务器都不管用了。
              1)  对于那些对于性能要求极度苛刻的大负载应用，比方说阿里巴巴，拥有中国最强的Oracle DBA团队，已经把Oracle的配置优化到极限，已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程，甚至不允许程序员创建触发器、不允许程序员创建表的外键约束，外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层，加重数据库服务器的负担。 
              2)  我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。
              3)  留恋存储过程的，我想大多数人可能是最近几年都脱离了实际的开发的人。记得当初某人曾说，用存储过程吧，反正这个业务10年也不会发生变化。而且我还不是在一个人那里听到的这个说。但是这些系统仅仅过了三年就要升级，因为业务规模和企业需求的发展大大超乎当初的设想。
              4)  不要以为一种技术理论开始流行仅仅是人们的炒作。把业务分层，与数据和显示、硬件隔离的思想，已经出现了20年了。可以说分层的思想一出现，人们就在说这个问题。而且一直对这个问题的看法如此一致。这些都是建立在大量的大规模企业应用的基础上得到的血的教训带来的。
              5)  可以说即便硬件的更新再快，也赶不上需求的要求。CPU和IO瓶颈，昨天是，今天是，明天依旧是问题。而一旦需求来了，不会有时间给你去解决这个问题。这个时候最简单的方式，就是直接加点应用服务器。这个方法比任何方法都见效快，而且往往也最便宜。 
              6)  有点疑惑，如果把大量的业务逻辑放到webserver来处理，那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理，然后dbserver只返回少量处理后的数据多。 
              7)  当访问量大规模提高之后，webserver和dbserver这种传输的消耗肯定也要打规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的？
       我不妨给你一个数据参考参考，JavaEye每天是70万页面访问量，处理80万动态请求，访问峰值的时候Web服务器和DB服务器之间的网络数据传输量是2MB每秒，平均每秒传输不到1MB。 我就算你的企业应用系统每天有800万动态请求，你服务器之间的峰值数据传输量也不过20MB每秒而已。好吧，也许你又说JavaEye处理的数据量不够大，我再给你扩大5倍，算你峰值每秒数据传输量100MB，够不够大？ 可即便如此，现在随随便便的普通台式机的网卡都已经是千兆网卡了，处理你这峰值每秒100MB简直轻而易举，更不要说专用的高速服务器网卡了。对于大规模的群集应用，有更加高速的光纤，每秒几GB都不成问题，但你要真有每秒几GB的数据量，嘿嘿，老实告诉你，中国还没有多少企业应用系统有这么大的网络数据传输的需求。

       6. 非极度依赖数据库的业务逻辑，我想不会有人放到PL/SQL中去。

       7. 设放在pl/sql里的都是那种极度依赖数据的业务逻辑（我们公司就是这样）。来来回回的找表运算，来来回回，运算。这种运算。你从PL/SQL中抽出，现在放到应用端来做。好，过了一年，发现数据量大了，速度不够用了。这个时候你加应用服务器有用吗？没有用，加再多都不行。因为真正的耗时最终还是被传递到DB上面。你只能加强，优化DB。没有别的办法。

       对于大数据量的OLAP运算，根本不能放在应用服务器端来执行。因为很容易就会让你的应用服务器内存溢出，导致你整个业务系统无法访问。

       对于企业应用来说，有的是OLTP型的，有的是OLAP型的，也有兼而有之的。对于OLTP型的应用逻辑一定要放在应用服务器来执行，而对于OLAP型的应用的确适合使用存储过程来实现，用应用服务器去运算根本不行。不过一般说来，大部分的OLAP运算并不是实时性要求很高的，所以往往可以用存储过程实现以后，作为后台任务定期执行，这些后台任务往往会执行好几个小时才能结束，然后把执行结果保存下来。让应用服务器在展示报表的时候读取最终查询结果。 
 
       应用服务器群集和存储过程本来没有什么关系。但如果有人说，业务逻辑应该写在存储过程里面，就有非常大的关系了。而这个帖子所要讨论的问题就是：业务逻辑究竟应该还不应该写在存储过程里面。显然很多人认为：不管三七二十一，业务逻辑都应该放在存储过程里面。

       而我要告诉大家的是，除了那些对大数据处理非常依赖的操作，其他所有的业务逻辑统统不应该用存储过程来实现，而应该放在应用服务器层实现。而WebSphere群集解决的就是当应用层业务逻辑负载太大的情况下，如何进行扩展的问题。

       不过话说回来，并不是每个企业应用的瓶颈都在数据库端，即便瓶颈在数据库端，不一定非要通过优化DB来解决，其他的办法多的是。

以前听说wp没建一个分类就创建一个分类表，记得那个博主说wp效率低在这里。 这几天给一个站点分析优化策略，突然想起来wp这件事，不由得佩服wp作者的聪明之处：通过反范式设计，降低消耗，提高效率。硬盘空间低廉，但是cpu、内存资源成本高。

举例如下（无图)：

原始设计：

1. 文章分类表。id,className,description,others…

2. 文章表。id,title,contents,others…

3.文章、分类关链表。classId,articleId.

文章记10000条，分类记10个。此处的表设计符合第三范式最简的要求。

查询某个分类下前10条记录(列表页用)(sql 语句)：select  id,title,createDate  from article where id in (select articleId from articleInClass where classId=10);(此处的 in 可以用表关联或其他方法来优化，此处不考虑这些。)

至少需要查询两张表，并进行关联查询。

改进化后的设计（每个分类一张表）(暂时以其中一个举例)：

1 . 某分类表(articleInXxxClass) id,title,createDate

2.文章表(article) id,title,author,description,contents,tags,createDate.

这时候取该分类下前十条记录就很简单了：

select top 10 id,title,createDate from articleInXxxClass

效率很明显就上去了。请使用sql跟踪监控工具测试一下就能看到。

关于文章更新、添加、删除等同步问题，封装到存储过程里面就行了。

个人见解，思路不对的地方请多多指教，谢谢。

李红民 2009年9月7日10:49:48

备注：文章同时发布到http://lihongmin.com/?p=185 和http://shenxian.cnblogs.com/ 转载请标明出处，谢谢。
不好意思，标题的反范式被我写成了反模式，引起一些错误理解，不好意思。

排序分页，SQL2000，遇到如下问题

select identity(int ,1,1) as pid, id ,username,classid into #collectionInfos from pk_collection

select * from #collectionInfos

 ---

id 是原表标识列，自增。

数据库报错如下：

服务器: 消息 8108，级别 16，状态 1，行 1
无法使用 SELECT INTO 语句向表 '#collectionInfos' 中添加标识列，该表中已有继承了标识属性的列 'id'。

网上查到的方案都是去掉标识列，去掉了标识列还有多大用处啊，汗。

想了想，转化一下，如下：

----
select identity(int ,1,1) as pid, cast(id as int) as id ,username,classid into #collectionInfos from pk_collectionInfo

select * from #collectionInfos

问题解决。

mysql：Out of range value adjusted for column 'crc32key' at row 的正确 解决方法.

网上的方法都是修改sql mode，去掉 STRICT_TRANS_TABLES。我碰到后发现问题在于插入负数时候出错。解决方法是将该列的UNSIGNED去掉。