最近一直在做下一代CSDN社区的设计，在帖子编号到底采用Guid，还是自增Int选择的时候，花费了不少心思。
最后的确定的方案是采用Guid。
原因如下：
Guid 虽然在搜索、索引寻找的时候，速度肯定比不上Int型字段。
但是，如果帖子编号采用Guid，在提交到中间层之前，就可以知道要增加的这个帖子编号是那个。
而如果使用自增Int，如果中间层的应用逻辑需要在增加到数据库之前执行，那么我要做多少费时的操作才可以知道要新增的这个帖子编号是多少。如果这个中间过程比较费时，完了，肯定超时。
在大数据量下，使用Guid的上述好处体现的非常明显。
使用Guid，中间层可以引入队列的概念，表现层只要简单的向中间层待处理队列中增加一条，既可以返回了。而不用等中间层和数据库层处理完毕。
微软的BizTalk 中表示编号的是Guid，而不是Int，这就是其中一个原因。同时很多大型系统，也是使用的Guid而不是Int。 当然，你也可以使用一套自己的编号方式。不过Guid和Int是最简单的而已。
Guid 类型字段跟Int类型字段速度对比数据，可以参看以下Blog：
http://www.cnblogs.com/zhenyulu/archive/2004/07/20/25816.html
摘要：
在性能和灵活性取舍的时候，插件做成一个虚假的插件。
正文：
最近一直在进行下一代CSDN社区的详细设计，其中各个社区都需要有自己的特色，苦恼的地方就是灵活定制和性能的取舍。
插件系统就是相当灵活的系统。
http://www.cnblogs.com/muddle/archive/2004/06/11/4762.html
这里对插件系统的描述就相当不错。摘抄几句：
插件系统就是指 当宿主程序开发好以后，可以开发一些符合自定义规范的程序(插件)，来扩充宿主程序的功能。
插件系统的设计注意点为：
1. 宿主程序如何知道插件的存在；
2. 插件如何从宿主程序获得必需要的内容；
3. 插件之间如何交换信息；
4. 如何对插件进行扩充(也就是说每一个插件都可以作为一个宿主程序)；
5. 考虑插件升级，等其它因素；
要实现以上灵活的插件系统，.net 下使用反射是必然。但是使用反射又有性能的问题。
反射的性能可以参看以下链接：
http://blog.csdn.net/leafwiz/archive/2004/10/18/141882.aspx
http://nickchen.mblogger.cn/posts/28131.aspx
另外，如果每个插件要用到自己的数据库的话，更麻烦。在社区设计中每个插件涉及到数据库就很明显，比如CSDN 社区的积分制可以被认为是一个插件。保存积分就需要数据表。而这个数据表又不是孤立的。
这样灵活的系统下，性能必然成为很大的问题，而社区一般都是众人集中的地方，性能、用户体验是第一要素。
考虑到以上的问题，在CSDN下一代社区开发中，我觉得采用一个中庸取舍方式比较好。
首先这个社区的插件应该都是由我们组织开发的，我们清楚有哪些插件。这样就不需要考虑特别灵活的扩创一个新的插件，而只需要考虑灵活的调用一个插件，同时调用时要考虑性能问题。
这样在新设计一个插件的时候，可能会比较麻烦。但好在这不是第三方完成的，我们是可以控制的。
我们在程序架构上，就可以假设这些插件都是存在的，只是调用不调用的问题。
这其实就变成配置参数的思想，而不再是插件的思想了。
只不过我们为了为了维护方便，仍然采用插件的思想，把每一个插件相关的操作，尽量集中到一个应用程序集中（这里仅仅是尽量而不是强制要求）。部署的时候，方便管理。
这个虚假插件系统中，甚至可能部分插件是混杂在一起的（比如数据库中，宿主数据表和插件用到数据表被集成到一个表中，宿主程序和插件程序对该数据表同一行不同列的操作，可能会被集中到一个函数中完成）。
这就是一个虚假的插件系统。但是他是照顾了性能，又有相当灵活性的。
虚拟组件的思想再整理
1、可以预知并控制有哪些组件；
2、性能优先的原则下，尽量使用组件、插件思想；
3、程序中具体实现，是通过配置调用与否来定义的，代码直接调用相应功能。而不是用反射机制。
4、代码举例：以下情况都是允许的
4.1 一个函数体内，我们根据配置来分类运算。
4.2 一个函数体内，根据配置，分别调用不同组件的不同方法；
5、数据库举例：以下情况都是允许的。
5.1、所有组件跟宿主需要用的数据表字段，是在一个数据表中的；
5.1、所有组件跟宿主需要用的数据表字段，是在不同数据表中的；
注意，如果我们事后需要新增一个插件，可能代价会比较大，考虑到这种情况，设计开发的时候，就要求程序员在考虑性能的前提下，尽量插件化，方便扩充。
这种要求，在负责外部需求的时候，可能是根本不可实现的，但是如果是内部需求，开发者就是其中一个用户，也是设计者。这反而是可以达到的要求。比如CSDN的社区。就是这样的一个实例。
结论：
以上的中庸取舍思想，其实在软件开发中很有意义，因为我们的实际项目需求，跟某个设计模式的理想状态总是有差别的。
附带说一下：网站的总体性能，总体体验，主要是由用户最常使用的功能决定的，如果你的一个优化把用户最常使用的功能反应速度提高了，而把不常使用的功能反应速度增大了，这仍然是一个好的性能方案。
昨天去参加微软嵌入式开发基础教育大会。微软在嵌入式方面主要有两个产品：WinCE 和 WinXP Embedded 。需要注意的是，这两个产品都是嵌入式产品，他们都可以定制安装，也就是，你可以选择安装这两个操作系统。比如，某些功能不安装等。
这两个产品的应用场景区别如下：
WinCE 可以适用于多种CPU的环境，而不仅仅是X86的CPU（ARM, MIPS, SHx and x86）。
WinXP Embedded 仅仅适用于 X86 的CPU
WinCE 使用的是WIN 32 API的一个子集和不完全版的.net即（.net Compact Framework），不是所有。
WinXP Embedded 使用的是所有的Win32API和完全版的.net（当然，如果你配置WinXP Embedded的时候，某个功能没有配置上，这个功能对应的API也就没有了）
WinCE 最小可以做成 350KB大小
WinXP Embedded 最小可以做到8MB，这还仅仅是显示一个“Hello World”
WinCE 的实时性要比WinXP Embedded 要好。
下面我们来据两个例子，来说明它们的应用场景：
一个高速公路收费系统，它用到的机器是普通的台式机，但是希望使用到的机器除了做收费用外，不要有其他功能，比如没有我的电脑，没有IE，没有媒体播放器等等，开机进入的就是收费系统界面。这时候，就可以使用WinXP Embedded，而且比起WinXP 来说 WinXP Embedded 等便宜。
又比如，一个工控系统，由于用的不是X86的CPU，而且实时性要求比较高，甚至这个系统没有界面，是一个及时记录，及时反映的系统，这时候，我们就可以用WinCE来完成这个需求。
今天去香格里拉饭店参加IBM的开发者大会，也小小的追星了一把。这个星就是UML创始人之一 James Rumbaugh 。
自从 Rational 被 IBM收购以来，IBM的开发者大会就很有听头了。记得去年IBM开发者大会的时候，感觉自己的收获就没有这么大，James Rumbaugh 今天早上介绍了UML的发展，明天还有人讲UML2.0 ，很值得听。
下午我呆的那个会场是专门讲软件工程中需求相关的内容。 Use Case 、Business Use Case、开发高质量的Use Case 、需求管理，连续听了4节关于需求分析的课，受益匪浅。
Use Case 是描述需求的，它是从用户的角度来描述的，它不应该涉及到具体设计，我们应该按照这个原则去创建 Use Case 。
在整理这篇blog 的时候，看到一个很不错的UML网站， http://www.uml.org.cn/index.asp Mark到这里。
网站的一个重要指标是用户体验，但是用户体验很难被量化。很难评价那个好那个不好。
http://www.sitepoint.com/print/quantify-user-experience
上面给的链接，就是一篇对用户体验如何进行量化的文章。
其核心就是把用户体验分成：
branding
usability
functionality
content
按照这4个方面，对每一网页功能进行评分，然后用类似下面图的方式进行展示。
更详细的，请看上面给出的链接。
今天公司一个同事的电脑，开机就报：“NTLDR Is Missing”。
网上一搜索，微软的知识库中写这个原因的时候，如下写道：
http://support.microsoft.com/?scid=kb;zh-cn;320397&spid=1131&sid=global
原因
如果 MFT 根文件夹碎片较多，则可能会出现此问题。如果 MFT 根文件夹包含多个文件，则 MFT 就会变得非常零碎，以至于需要另外创建一个分配索引。因为文件是按字母顺序映射到分配索引中的，NTLDR 文件可能会被推到第二个分配索引中。如果发生此现象，就会看到本文“症状”部分中描述的错误信息。
一般情况下不将文件写入根文件夹。如果一个程序定期在根文件夹中创建和删除临时文件，或者将许多文件误复制到根文件夹，就会造成这一情况。
至于这个问题的解决方法，有很多，下面罗列个连接：