一路向前走

这也不让用，那也不让用，那开发系统做什么啊？那SQL里边搞这些干嘛？

有用

很好，很不错的方式，谢谢~~~ 但如果要加事件委托，如： AnotherProject.Form1.ReturnValue += new AnotherProject.Form1.ReturnEvenHandler(frmReturnValue); 如果用这方法，成 f.ReturnValue += new AnotherProject.Form1.ReturnEvenHandler(frmReturnValue); 肯定不对，怎么办呢？

@toEverybody object[] paraArray = new object[]{ "参数1", "参数2" }; object obj = System.Activator.CreateInstance(curType, paraArray); 了解System.Activator.CreateInstance,可以去查一下资料!

如果我要传入AnotherProject.Form1的一个参数怎么办？ 如Form1的构造是这样的 string temp; public Form1(string cnstr){ //initi..... temp=cnstr; } 这时怎么把参数值传入呢？？

看了一上午，很经典，学习了！

不错，谢谢

挺实用~

尽管中国人口众多，但愿还是不要发生第二波儿.

提到墨西哥不得不说一说，这个国家真不厚道，咱们非典那年，女足世界杯本来应该咱们办，结果咱们考虑到大局就不在咱们这办了，大家看现在墨西哥墨墨迹迹的。

另外楼主文章是几天前的呢？国内已经有确诊的了吧，只是还没有死亡报道。

中国至今还没有，只有香港有一例???
什么年代的新闻

比想象的要恐怖

早就看到过了

我也收藏了，我已经用上了。3Q

楼上的，这不是重复造轮子啊。楼主的这篇文章写的很好啊，而且为我们提供一种拼音的解决方法。而且楼主的共享精神值得鼓励。

我曾经也开发过一个类似的，可以支持多音字，包括声调的转换。
http://www.cnblogs.com/sunli/archive/2007/11/21/967294.html
这是我写的一个算法介绍。

人多了，就是力量大，佩服大家了。

强大哦 中国文化博大精深 哈哈

http://www.wuchenwenyaqi.com/cpzs.asp

"囧"测试失败，囧是什么字符集的啊？~

代码太多了，建议楼主放个打包下载

微软有这样的类库，为什么还要写这么多啊？去微软网站下载个。

谢谢楼主分享，收藏！
楼主辛苦了！
这些东西确实不好找，我以前费了好大劲才写出来一个很简单的汉字转拼音。

@Freewind
一级汉字是按拼音排序的.
在GB2312-80基本集中已经定义了其各个一级汉字的拼音.
这些一级汉字的数字就是基本集中标有拼音的汉字的机内码十进制表示法.

待会来试一下微软的那个好不好用。

散列表，O(1)查询复杂度。
.Net中Dictionary<T>、HashSet<T>。
改进速度最佳之方法也。

学习了...强啊，，你那些数字怎么来的?

楼主加油，做一牛B的气死微软！

楼主辛苦了 找全这些都不容易

鼓励一下，百花齐放是好事。

带音调不？

不错,ms的拼音指南就可以识别多音字,这里有个思路:先将汉字串分词,可以用中科院的分词包,然后到词库里查,每种输入法基本都有词库,比如:重庆,重大,对应的拼音分别是:chongqing,zhongda.这样就能识别多音字了,希望继续完善,非常感谢博主的工作.

lz造轮子了，建议使用Microsoft Visual Studio International Pack 1.0，多音字、笔画、同音字这些功能都有的。https://www.microsoft.com/downloads/details.aspx?FamilyID=44cac7f0-633b-477d-aed2-99aee642fc10&displaylang=zh-cn

楼主牛人，我也曾想做个这东西，研究过一下，后来没做了，你把数据都放在代码里，恐怕不是好办法。遇到多音字怎么解决？

Microsoft Visual Studio International Pack 1.0 SR1:
http://www.microsoft.com/downloads/details.aspx?FamilyID=44CAC7F0-633B-477D-AED2-99AEE642FC10&displaylang=en

其实微软提供了从汉字获取拼音的类库.

ms有提供一个什么什么全球化的小组件 里面自带转全拼 我用过 效果还不错，而且可以识别多音字.不过根据词组来选择多音肯定是不行的...

不错了，有时候还真能用上，先收藏了。

这样内容已经很多，还有数据设计方面的内容都有

我有个疑问，就是你的这些sql优化是放在开发的时候，还是放在运营的时候？

下面这个可以用not exist优化吗？应该不行吧。
例子
SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN
(SELECT CUSTOMER_NAME FROM CUSTOMER)
优化
SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist
(SELECT CUSTOMER_NAME FROM CUSTOMER)

对于sql调优没概念的，看我以前写的一个入门文章：

http://blog.joycode.com/juqiang/archive/2007/01/19/91848.aspx

居然不在园子里面，找了半天没找到，汗。。。哪天都挪过来。

杨过和其他几位同学，索引是否好用，不是说用不用。如果非要找一个好用的标准，那么就是index seek最好（没有RID lookup），index seek+rid lookup其次（这个要看rid lookup成本多高，太高了就非常差），index scan再次，table scan最差。

你的那个somecolumn like '%somewords%'，是因为在somecolumn上建立了索引，所以有了index scan，而不是table scan。而这种like，包括楼主讲的N中不符合SARGs规范的写法，都是因为sql db engine无法用二分叉找法快速的在index node和index leaf上进行搜索。即，不能seek，只能scan。db engine在匹配index key的时候，是根据最左原则匹配的，这就是为什么%somewords%不能seek，为什么abs(somecolumn)>10不能seek，为什么substring(somecolumn,5,1)='C'不能seek的原因。

如果有hash join、merge join等，那么在某些条件下，把数据归集到临时表，再进行处理，这可能会避免join，会更好一些。

对于sql调优，没有什么不变的公式。SARGs是一个，我讲的index seek>scan是一个。但最终的手段是通过降低I/O来提高速度，缩短时间。

网络上关于sql调优的文章实在太多，但是那些1、2、。。。100的准则实际上毫无用处。你多看执行计划、多看索引怎么走的，基本够用了。

推荐大家看本书：sql 2008 internals（我不知道有没有中文版的），或者看2005的inside系列也行，看db engine和storage engine那两本就差不多了。

b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联,
这个没有看懂，
你是如何查到符合条件的供应商的(还不是用like '%%').

in 和exists没有优劣之分，存在即是理由。只是要根据实际情况择优而用。

@Freewind
很遗憾，你说的没有办法优化，不过在mssql下可以使用FTE

左like是非常耗费性能的

@Jerryfy ZH
不扯，这个是正确的。
因为你对字段的操作就需要引擎在每选取一行数据的时候对列进行计算或者对比，所以不会利用上索引。

我觉得这些东西没必要在这争来争去，自己写个demo实验实验就是

多看执行计划

刚在我机器的sqlserver2005中截了张图，对like语句做了“显示估计和执行计划”，图片地址如下
http://img.luckty.com/jimmy/090408/like.jpg

这张图应该能表明sql2005的智能分析能力，执行计划中显示已经调用了索引

(另外：今天博客园的评论功能很怪异，动不动就是相同的楼层)

第一条，理论上讲是这样，但是实际应用中，如果过于偏重性能优化，会让系统的易用性变得很差，比如很多web应用中都有搜索会员/日志/文章...这些常规功能，使用者不可能记得每个会员的名称/每篇日志的tag/每篇文章的标题等，这时候最方便/有效的我想还是like '%...%'这种方式，虽然性能差一点，但起码很好用，从我这几年开发web系统的经验来看，真正达到数百万数量级记录数的网站应用极少（也就是那么几个大门户，而到了这个数量级后，单纯的sql优化其实也作用有限，还是得依靠硬件手段等其它来提升性能），sql性能优化与系统易用性之间，还是要有一个平衡点，以前记得谁说过，技术中的任何一点小小失误，都会使很多的优化成果化为乌有，只要在使用中不犯一些相对“低级”的错误，比如一张表的字段达到50个以上甚至上百个字段、不使用任何索引之类，何况现在的数据库系统也在不断进步，很多以前认为性能不佳的语句，现在数据库也能很好的智能优化了

第一条，理论上讲是这样，但是实际应用中，如果过于偏重性能优化，会让系统的易用性变得很差，比如很多web应用中都有搜索会员/日志/文章...这些常规功能，使用者不可能记得每个会员的名称/每篇日志的tag/每篇文章的标题等，这时候最方便/有效的我想还是like '%...%'这种方式，虽然性能差一点，但起码很好用，从我这几年开发web系统的经验来看，真正达到数百万数量级记录数的网站应用极少（也就是那么几个大门户，而到了这个数量级后，单纯的sql优化其实也作用有限，还是得依靠硬件手段等其它来提升性能），sql性能优化与系统易用性之间，还是要有一个平衡点，以前记得谁说过，技术中的任何一点小小失误，都会使很多的优化成果化为乌有，只要在使用中不犯一些相对“低级”的错误，比如一张表的字段达到50个以上甚至上百个字段、不使用任何索引之类

对于in，exists不能一概而论。在子查询中in适合于子查询数据量少的情况，exists适合外层查询数据量少的情况。因为用in是先执行子查询，而exists是先执行外层查询