理想与现实之间

有索引的时候，join会使用index seek，没有的时候就table scan。而且，有索引的时候，join可以使用merge join，而不用是nested loop或者hash join，要快很多。

即使不是join，如果你要找的都是非null的值，那么有null不会导致索引效率不高。楼主先去搞明白什么是index seek什么是index scan，什么叫merge join之后再来建议怎么加索引这个问题。

优化查询是很复杂的事情，至少能看懂execution plan之后，再来给建议比较好，省得误导别人。

2.0里面只支持delegate参数的协变，但不支持泛型参数的协变。

在2.0里面 IEnumerable<Stream>，和IEnumerable<FileStream>是完全没有关系的两个类，即使FileStream继承自Stream。所以更别提什么协变不协变了。

我还没有看过生成的IL，但除了in/out关键字之外，IL可能需要多的部分不会太多。反而是虚机本身会有很多变化。

看得不错，很实在

这不是语法改进。协变是从CLR的虚机层面支持的特性。

回Gray:
不可以，如果没有in和out的修饰，仍然是不可以进行协变的。这是编译器的规定，为了提高对现有代码的兼容。有时间的话，我会在后续的文章里解释一下原因。

哦 不过 有一个重载上的问题。。。

我后来又想了一下，我们那个visitor模式应该是可以运行的，只是要声明为out而已。有高阶函数的时候，out和in的涵义已经完全不对了。

另外，interface本身就是高阶的，我会写个博客说明一下 =。=
另外之后的另外：你星期一把dev10的VPC给我，我要试验一下 = =

其实不光是boxed value type，对于普通的reference type来说，obj reference也是以4byte的methodtable*开始的，所以这个obj reference到this point的偏移应该是一个general的过程。

嘿嘿，学习下~

我的是影印的，没有电子本，所以没办法share呀

2005的话，直接用XQuery吧

其实用这么简单的语句来考验optimizer不是太合适。Optimizer的规则其实相对来说是挺简单的，因为编译的时间不能太久，尤其是复杂的语句的时候，常常只能找到一个次优解。要SQL得到一个最优解不太现实。

缓存页的问题，Storage Engine一定是先去内存里找那个PAGE，找不到才去读硬盘。

像join column上有clustered index，且只有两个表join的这种完美条件出现的概率太小了。说完美是因为这样会留下太多可优化的空间，总有optimizer想不到的。 :)

申请加入。
用户名 hush

给每个table都加一个没有实际用途的ID之类的列，然后还把clustered index放在上面，真是非常令人发指的行为。clustered index对效率的帮助，完全被浪费了。很多时候，确实是建在时间列上比较好。

自增列其实也最好能避免使用。看到很多为了获取自增之后的值而导致的Deadlock。另外，如果你将来想要用replication，自增列也会给你添很多麻烦。

一定要有一个clustered index，是GTSC-DSD Team一贯给客户的建议。如果你从GTEC的哪个SQL的工程师那里听说要用HEAP，告诉我名字，我让我们Tech Lead去骂他　:)

不使用Heap的很重要的另一个原因是，在Heap的情况下，SQL没有可利用的statistics信息。如果你在做join的时候，SQL需要通过统计信息来判断经过filter后的行数，然后决定使用何种方式，如果是Heap，那么SQL缺乏这方面的信息，经常会选错join的方式。

如果我没有理解错，你说的适用于Heap的状况，是指那种读取了表大部分的数据，导致non-clustered index seek + bookmark lookup的效率低于table scan。

但事实上有clustered index的时候，也是可以做clustered index scan的，效果上和table scan一致的。

当语句返回的行超过1/3的时候，SQL一般就会用index scan而不是non-clustered index seek + lookup的情况。所以说你说的heap的好处是不存在的。

当然如果SQL没有index scan，可能的原因就是统计信息很久没有更新，造成SQL的误判。事实上，实际使用中遇到的问题通常是SQL太容易去clustered-index scan而不去seek。为此，SQL 2008里面加了forceseek的hint。

第一条是不对的。在任何时候都应该为所有的表都加上clustered index。SQL Server本身实现的方式导致，堆的情况下会有很多问题：
1. 会比较容易引起corruption，尤其在SQL2000及之前的版本。
2. 没有办法给出精确的数据库使用大小的报告。

其次，使用clustered index的key来查找一行，和使用rowid查找一行效率是一样的，从概念上来看，似乎多一个查找的过程，其实从实现上来看rowid也会有一个查找的过程。

最后，如果没有clustered index，如果你的non-clustered index没有cover你的查询，很容易导致table scan，会导致性能大幅下降。有clustered index的情况，还有可能clustered index seek + bookmark lookup

每课大概是多少时间呢？
曾经给东软讲了一个类似的一天的课程，似乎时间上有一点赶。

inside rotor cli　这本书，作者有share了电子版，可以在下面这个地址下载到。

http://www.cs.colorado.edu/~nutt/DVM/

Shared Source CLI Essentials　没有电子书，国内也没有引进，实在没有办法了。

to 老翅寒暑:

在自已没有对.net泛型进行研究之前，不要随便去指责别人。.net的泛型和C++的template完全不同。.net的generic是运行期行为，但为了能在编译期做类型检查，所以使用的限制也要比C++的template来得大。

好像没有什么必要吧？如果说随机数的产生和seed有关，但一个Seed可以产生一列随机数，获得一个Random的实例之后，再调用Next()之后，只和初始的Seed有关了，所以不存在CPU过快，产生相同随机数的问题。

CPU过快，产生相同随机数是因为每次new一个新的Random实例，然后在新的实例上调用Next()方法，这是误用，和Seed没关系，不然毫秒级的系统时间足够产生可用的随机数列了。

PS一下，这个问题在VS2005里面也有...

overflow不能算是错误，某些散列算法中，要有意overflow才行

是那个判断出了问题，或许是JIT的BUG，这两个程序生成的汇编代码是不一样的...

这个问题可以进一步简化为:


int a = 0x79de61c0; //2044617152;
a += 0x12345678;
//a should be 0x8c12b838; //-1944930248

if (a > 0)
{
Console.WriteLine("greater than zero");
}
else
{
Console.WriteLine("not greater than zero");
}

string str1 = a.ToString();

这个是诡辩的典型教材，主要是偷换了天的概念，一会按24小时算，一会儿按8小时算。

(1)每天你花30分钟时间喝咖啡，加起来每年23天，剩下68天。

0.5*365/24=7.6 他按每天8小时算，天数当然多出来了。

(2)你每天有16小时不在工作，去掉170天，剩下91天。
每年有5个节假日，公司休息不上班，你只干15天。

他已经在之前把不工作的16小时扣掉了，所以即使5个节假日只应该扣5*8=40小时，一天多一点罢了。
(3)每天午饭时间你花掉1小时，又用掉46天，还有22天。
明显午饭都是自己的时间，不应该算在工作的8小时里。


总结：其实很容易算出工作多少天的。工作日一共是

52*5 - 5 - 14 - 2 =239天

每天工作 8-0.5=7.5小时

所以一共工作7.5*249/24=75天

请首先确认是不是我文章里描述的这个问题，如果是的话，先找到odbcconf.exe的目录，在命名行里切换到相应的目录里，运行odbcconf，上面的命令当中的%systemroot%要替换成你的windows的安装目录。

有中国特色的那些名词是很讨厌， 楼上的Ariel 别光喊口号，你到是来翻译翻译看“处级干部”、“老干编制数”这些词

我觉得楼主说得还是有一定道理的，知道一样东西的优点以及怎么使用只是入门的第一步，知道它的缺点以及什么时候不能用，才又进了一大步。

不过楼主的标题似乎有点太偏激了。STL的一大好处是可扩展性，其实楼主可以试下定制Allocate呀。

海天一鸥说的第一种方法也很好破解，可以写一个伪验证程序就可以了。很多需要去服务器端验证注册的程序都是这样破解的。

像这种先 反汇编->改代码->汇编 的crack方法还比较容易对付，我只要用native code来写几个关键函数，编译到assembly里去就行了。

ildasm对于嵌入native代码的方法是无能为力的。

如果你有查阅过IIdentity的文档，应该就会发现在Name属性下有这样一句话：

Name is typically set to the empty string ("") for an unauthenticated entity, but can take other values.

null意义接近于“没有用户”，但即使是未登录的用户，也算是匿名用户并不表明“没有用户”，所以在这里用空串是完全合理的。这个和Cookie的情况不一样，Cookie判断的是 是否存在这样一个cookie，当然应该用null。

确实有点胡扯的嫌疑。

你文章里说“却写出了许多过程型的代码，不是技术的问题，是思维方式的问题。请尊重个体。 ” 那么照你看中国人的思维方式就是过程型的喽?可是面向过程的编译模型还是外国人提出来的呀？

就算承认你的关点，那么外国人的思维到底是面向过程还是面向对象？

形而上的关点很容易拿来牵强附会，实在没有什么意义，不如踏踏实实研究一下技术，没必要扯到意识形态的东西上去

好强呀，有没有分析魔兽世界纹理的？ :p

你可以选择用VS2005开发，但是用nant来编译。

但是就像Ninputer说的一样，如果使用可视化编辑器或者代码生成向导的话，很可能会误用一些.net 2.0的特性。

关于用nant编译，可以参考一下
http://www.cnblogs.com/hush/archive/2004/12/12/76054.html

呵呵，在VS2005里不仅可以拉到设计视图里，还可以拉到html代码里。 :)

多态可不是什么隐藏变化 ,依赖反转,封闭开放原则。多态就是多态，简简单单的一个面向对象特性，不用为它套上什么高帽子。

至于我们可以利用多态来实现的那么多设计模式，那是另外一回事。就像一把小刀，有些人只能用来削铅笔，有些人却能用来雕刻艺术品，但小刀就是小刀，没必要神化什么。

这里原诗，大家可以对比一下 :p

http://www.blackdog.net/holiday/christmas/twas.html

看来要注意一下，我一直喜欢建一个blank solution，然后再往里添加东西...

硬件公司并非不用设计模式啊，设计模式是在实际被证明有效的代码结构，并不是GoF书上的才是设计模式。

在硬件公司里因为追求效率的关系，不可能使用OO，对硬件编程来说虚函数就是性能毒药，:p

不过，你也可以发现领域专属的设计模式呀。即使GoF书里的那几个设计模式，如果应用的环境不对，就很容易变成反模式了。 :)

没有PDA，其实很多时候我还是觉得用一个本子来记比较方便，嘿嘿

是啊，所以博客园准备搞一个e-magzine啊

我觉得关键不是能不能做的问题，而是想法的问题，wallop也是一样

我总会比较迟钝一点...^_^b

楼上的说得真好！

总觉得自己罗嗦了一大堆，也没说到点子上。

string的==操作是重载过的，其结果取决于string引用所指向的字符串的内容是否相同，而不仅当指向同一个字符串时，才会返回true，这并不同于Object.ReferenceEquals()，考虑以下的代码：

string s1 = "hello";
StringBuilder builder = new StringBuilder("hello");

string s2 = builder.ToString();

if (!Object.ReferenceEquals(s1, s2))
Console.Write("the two string references don't refer to the same string object, ");
if (s1 == s2)
Console.WriteLine("whereas the two strings themselves are equal.");

我完全不同意你的观点呢！基础是很重要的。

我敢打赌说你找不到哪个人说“不要学vb、java、c#、Asp、html等，要学习vc（或者C++）”！

我只听人说过“不要急着学VC（MFC），先把C++学好”，这当然是对的，前提是你要知道VC和C++不是一个东西。

就像我看到很多人号称会用asp.net，实际上却只会拖拖控件。连段像样的代码都写不成。难道他们不应该去补习一下C#语言的基础？

另外，一个没数据结构的基础，很难想像他能写出什么有用的代码。

很多打下的基础，会让你在不知觉中受益，就好像你现在可能不会觉得，你能写下这个blog，完全是拜小学语文老师为你打下的基础所赐.

:) 庆祝一下

VB的那本，在dearbook有原版卖呢! 不过价格当然...

我要说spring.net真的很好用