一、第一到四章主要讲述了，分层架构思想，数据关系映射，基本的数据架构图提出的基本思想。

二、第五章对后面章节的内容着了铺垫并发、事务、锁（如悲观离线锁、乐观离线锁） 、ACID原则等的基础内容。

三、第六章为后面的第十六章会话状态做铺垫性描述。

四、第七章讲述了分布式基础，为后面的分布式做基础描述，提出了尽可能避免过度设计、过度使用分布式，能单机解决的问题绝不使用分布式方案。因为跨进程的访问是很消耗资源的。提出了分布对象设计第一定律：不要分布使用对象。而且要紧可能小范围内使用分布对象，尽可能的发挥集群系能（通常总会需要对象分布到不同的进程中）。其提出在同平台下优先使用平台自己提供的远程调用机制，然后才是使用webserivce的方式。

五、第八章讲述了领域模型的基础提出了：脚本事务模型、表模型、领域模型，脚本事务模型注意依赖一直接书写sql等脚本来解决业务问题，其对于简单的应用比较合适，成本比较低廉。而表模型，主要是依赖于平台提供的dataset 、datetable等来直接进行数据的逻辑运算、对于规模不大的应用比较方便快捷在这一块.NET做的相当的方便。而领域模型主要是把所有的运算都以对象的形式来进行运算，在.NET种我认为是把数据库的值映射到类中，用类来进行逻辑运算，大量的使用了面向对象的思想来进行编程此模式对规模不大的运用成本太高，对比较复杂的和规模逐渐变大的系统后面的成本会逐渐的比其他2种模式的成本更低。而实际的运用中不可能只是其中一种模式在系统中运用，而是可能多种模式在系统中并存使用。对于本章当时自己为了了解几种模式的区别和能在一个系统中找出这几种模式，我也花了较长的时间去理解。

六、至此前面一致八章是第一部分，主要的是为第二部分着基础内容铺垫，使读者能有一个平滑的过程理解本书。 所有有的问题在第一致第五描述清楚的在后面将不再描述。

七、 第九章深入介绍事务脚本、领域模型、表模型，详细内如如第五。其增加了一个服务层的描述，主要思想是把内部业务逻辑进行封装（封装方式是3种模式）对外提供一个初粒度或者细粒度的访问接口（是对物业逻辑封装的方法，并不一定是个真实的接口）。

八、第十章讲述了表数据入口、行数据入口、活动记录、数据映射器。

1. 表数据入口：从数据库中取数据是取出全部数据，在dateset、datetable之间是有过滤器来选取其中的某条数据、update、insert也是基于dataset、datetable、等ADO.NET的几大对象的数据更新方式，如直接使用适配器的update方法等。其基本思想是分2步取数据，第一步是取出数据库中的所有数据（select * from　table，注：没有where语句）。然后在利用datetable的过滤器或者筛选器(select 、filter)通过过滤条件（如用已知的ID来过滤）来选取其中的某条语句，就得到一条数据；其是表模式的使用体现
2. 表数据入口的优缺点：需要读取过大的数据在内存中，占有较大的内存空间，cup压力大。对于小数据，或者对数据的操作运算比较频繁的时候直接在内存中运算比每次都去数据库中读取数据速度快。其对update的操作也不方便。还有可能存在数据实时性稍低的情况，比较读取数据到dataset等中取运算不能实时读取数据库中最新的数据。
3. 行数据入口：从数据库查询数据时，直接带有如“select * from  table where id=参数”的方式直接从数据库中选取具体的某行数据。他对数据的操作完全是基于数据库的，而不像表数据入口是居然ADO.NET对象的。Update 、delete的操作也是携带了where 条件直接对数据库的数据进行操作。其是脚本事务模式的体现。
4. 行数据入口的优缺点：直接对数据库选取的数据比较精确，但是当需要较多关于数据库的数据读取时，对数据库的操作过多，可能带来数据库压力比较大。对类似的数据需要多次的进行读取时，对性能有一定影响。
5. 活动记录：对数据库中的数据进行，通过数据映射后形成对象，然后相关的逻辑运算都在对象中进行，其必须依赖于数据映射。必须把数据库对象数据转换为类对象。对所有的插入操作、更新操作、删除操作、查询操作所需要的数据都是以对象的形式进行传输，如果是数据集在NET中可以利用泛型等来进行数据集的操作来进行对象间的数据传输；其是领域模型的使用体现。
6. 活动记录优缺点：必须依赖于数据映射，并且其效率在大部分情况下低于另外2种。并且其的代码量比另外2种更多，需要建立比较多的运算对象（类）。但是其在代码的编写过程中比较方便，而且如果需求变更时，对代码的改动量、和维护来说在大型系统中比较有优势。
7. 数据映射：把数据库的数据映射到实体对象中去。方便运算过程中直接使用。而不是需要对象数据时使用sql脚本去取数据。现在出现的大量的ORM就是这个东西如EF，linq to sql等都是这写东西。他省去了开发人员不懂数据库语言时的方便，只需多拽就可以实现从数据库中读取数据并且映射成类。但是其性能有一定的缺陷，但是现在已经做的很好了，在中小型系统中使用是完全可以接受的。

九、第十一章讲述了工作单元、标识映射、延迟加载方面的内容。

1. 工作单元：基本思想是把一组相关的操作封装在一个方法中，实现一次性提交，其需要的基础数据在更早时准备好，存在在特别设计的数组中，到提交方法时只需要提交即可。提交方法中包含有3个方法，一个方法是插入数据，一个更新插入进去的脏数据、然后是删除新插入的数据。这种模式如数据库中的事务是一个道理一样。但是我们可以把他的思想引入到代码。
2. 标识映射：把已经获取到的数据插入一个临时变量中或者缓存中，当要获取该对象时优先通过ID等标识从临时变量或者缓存中获取，如果获取不到在到数据库中查询在缓存。
3. 延迟加载：在数据运算时只携带运算相关的键（如ID），当计算需要跟多数据时在通过该键(ID)去数据库中(或者某个存储对象中)读取出对象的全部数据，实现一种延迟加载的方式。重影，键（携带一个或者多个真是数据）是真实数据的一个重影。使用方式有：虚代理、值保持器（类似标识映射的方式）、重影。如果延迟加载加载了多余的数据，时叫做波动加载。

十、第十二章讲述了标识域、外键映射、关联表映射、依赖映射、嵌入值、序列化LOB、单表继承、类表继承、具体表继承、继承映射器。

1. 标识域：其实就是通常说的主键一类的东西，用于在内存中和数据库对象管理起来，给表中的某行一个主键、然后内存中也有一个主键，然后通过主键即可以找带数据对象。该键可以是自增涨ID或者GUID或者身份证号之类的唯一值。同时又有表键唯一和数据库键唯一。表键唯一是在一张表中唯一的一个值；而数据库键唯一是指该键值在整个数据库中是一个唯一值。
2. 组合键：使用多个键值作为主键，只有多个键值在一起使才可以确定一个唯一的行。
3. 外键映射：把表A中存储了表A本身的主键同时其还存储了表B的主键，及通过表A存储了表B的一个主键值就可以找到表B中和表A关联的数据行了。
4. 关联表映射：在表A和表B之间增加一个表C存储表A的主键和表B的主键关联形成一行，就实现了A表通过 C表就可以找到B表关联的数据；此方法通常是在表A和表B已经存在并且修改表A或者表B时代价太大而是要的一种第3方表的形式。不足：大量的关联查询损耗性能。
5. 依赖映射：基本思想是在数据库持久化时，数据库中的某个类（依赖者）依赖于其他的类（所有者）。每个依赖者有且只有一个所有者。比如A表有列a.c而B表有多行a.c的值与A表的a.c相同；类似于一个目录下有多个文件一样的结构。
6. 嵌入值：把数据库中的某些字段的值用在类的实例化时，该类通过自身的一些计算拥有了一些拥有展示的值，形成一个实例类。而该类的值（除了从数据库中读取的），可以通过计算得来，如果把这些值直接存储在数据库中则可以提高效率（直接查询，而不需要运算）。
7. 序列化LOB：把一个对象直接序列化成字符串(json、二进制)或者xml后直接存储在数据库中。有json、二进制序列化和xml序列化，这个方式会导致如果类修改了，可能使早期存储的数据不能反序列化回来，导致数据丢失。并且数据是人眼很难看懂的必须通过程序反序列化后才看得明白。如果序列化的对象被多处拷贝以后，当想要修改其中的某个值是必须把所有的拷贝对象都拿出了执行并且修改。将是一个很痛苦的过程。
8. 单表继承：如有A、B、C 这3个类继承关系是A:B:C即C继承B，B继承A。则会有不同的建表的方式，而单表继承是把A、B、C所有的字段都建立在一个表中，所有的数据都存储在一个表中。这3个类随便怎么调整继承关系度不必修改表（新增字段除外），不需要连接表操作、可能是A类中没有的字段在表中也有数据列对应，比较多余，浪费数据空间。
9. 类表继承：同意是ABC这3个表分别为他们3个类建立3个表即A表、B表、C表，当调整3个类的继承关系时不必修改表，清新的类，没有浪费空间，但是其有多表连接操作，导致性能问题。如字段从A类移动到B类则必须同时修改表，实现对应。
10. 具体表继承：即给A类的字段建立一个表，而B类继承了A类，则B表的字段必须包含A表的字段和其自身的字段，C类继承了B类，所有C类对应的C表必须包含A类的字段、B类的字段和C类本身的字段。优缺点每个表都是自包含的，并且没有不相关的域，读取数据时不需要连接操作、只有类被访问的时候表才会被读取，分散负载。其处理主键比麻烦、不能把数据库映射关系抽象到类中、类中的字段修改位置改动比较大，如C类自己的字段如果调整到B类中择需要调子C表和B表，比较麻烦、超类上的一次查找需要检查所有的表，导致多处访问数据库，或者特殊操作，查找A类中的一个信息可能要查询A、B、C这3个表，或者比较特殊的查询操作。
11. 继承映射器：即在抽象类或者接口中定义基本的数据读取规则，而在实现类中去实现查找，去实现类属性和数据库字段的关联。

十一、第十三章讲述了元数据映射、查询对象、资源库。

1. 元数据映射：本身提出了代码生成和反射程序2种方法；反射是通过映射生成可执行的代码程序，如NET中的反射。反射调试困难，代码执行速度慢，但其具有很高的灵活性，可以动态选择程序的执行，可以把元数据保持到xml中等地方。NET的可以从dll中进行反射，并且NET的代码提示靠的也是元数据、其调试模式下生成pdb文件也属于元数据的一种方式，反射是当修改某部分代码时很难发现问题；而代码生成主要是输入元数据，输出映射实现的源代码。代码生成本人感觉是，想非强制类型语言（如js）可以动态构建、拼接js语句然后在执行拼接的js语句的一种方式。
2. 查询对象：是解释器模式在表示sql查询上的应用。客户端可以构造各式各样的sql语句，然后交有服务端去解释执行语句。服务端通过一定的领域模类构造出一些方便构造sql语句的方法，然后这些方法生成的语句叫由服务端去执行；比如linq to sql里面定义的一些方法，其实其本质也是解析构造出sql语句交由服务端执行生成。
3. 资源库：协调领域和数据映射层，利用类似于集合的接口来访问领域对象。其是定义对数据库访问的抽象类、或者接口；必须在子类中实现自己对数据库的查询具体对象接口、删除对象接口、增加对象的接口等。他定义了一个高层次的数据访问规则，有子类负责实现。由于其只是定义了高层接口，就不需要关心具体的数据源、高层接口负责业务的定义。

十二、第十四章讲述了MVC(常见的模式还有MVP、MVVM、PM)、页面控制器、前端控制器、模板视图、转换视图、两步视图、应用控制器。

1. MVC：视图充(V)当模型(M)的观察者、控制器(C)是视图（V）的策略；其本质就是观察者模式和策略模式的混合使用。
2. 页面控制器(MVP)：M:Model、V：View、P：Presenter;其原理是V修改了通过P传递给M，然后M修改后又通过P传递给V。
3. 前端控制器：对页面进行访问时，通常都要进行安全验证，安全验证是通用的，各个页面的逻辑和展现的东西却是不同的，所有在所有页面访问前都见上一个安全验证，使所有的验证逻辑都走相同的逻辑。在NET就如同HttpHandle一样，或者全局文件，的管道模式。
4. 模板视图：就是生成一个模板的HTML模板页，在需要修改内容的地方做标识，在运行网站的时候，把标识替换成网站需要的内容即可。
5. 转换视图：把一个页面需要的数据先保存在一个文档中，然后在对这个文档的数据进行转换成为html代码。 如我们需要的数据都在xml中，我们在用某种语言(XSLT是本书推荐的一种对于处理这种转换的最具有优势的语言)把这些xml转换为htmL代码。
6. 两步视图：第一步在动态页面中处理数据逻辑，然后最终代码会生成相应的html代码输出到客户端。我们假设在其第一次运行动态页面生成了最终的显示逻辑代码后即htmL代码，我们把生成的这些htmL代码截取保存起来。就把动态的页面转化为了静态页面，以后再访问的时候，就直接访问静态页面，而不需要走动态页面那么复杂的运算过程。其第一步是运行动态代码生成需要展现的逻辑，第二步是保存页面逻辑形成的html代码。
7. 应用控制器：决定运行那个领域逻辑和决定用那种视图来显示应答消息；如同MVC中的路由控制器一样。根据输入的命令来跳转到相应的视图逻辑中去。根据不同的命令来显示不同的视图。

十三、第十五章讲述了远程外观、数据传输对象

1. 远程外观：把需要的一组数据封装在一个粗粒度的方法中返回，其中粗粒度的方法调用了很多细粒度的方法。访问时提供一些基本信息，而返回时返回一组比较全面的信息，这些信息你每次运算可能只需要其中的一部分。如NET下webserivce就是一种比较好的远程外观。其实现了跨进程和分布式的数据访问，但其有性能损伤的问题；同时在这里还提到了会话外观，但本人对会话外观还未完全理解清楚。着重提供一组粗粒度的结果集，而不是细粒度的方法返回结果集。
2. 在远程外观中提到了服务层，其基本思想是把一些方法集封装成一个服务，供远程外观或者其他的调用。在服务器中不涉及具体逻辑，只是一个返回某项业务的服务。
3. 数据传输对象：在调用者之间传输数据的方式； 远程外观中粗粒度的结果集，必然导致不需要的数据在网络上传输，通常的方法是对对象进行序列化传输，有二进制数据传输、文本、json数据传输、基于（soap、wsdl协议的）序列化为xml的数据传输。数据传输必然存在服务端发送序列化后的数据客户端必须能解析服务端序列化后发回的数据，服务端和客户端对数据的封装必须能方向进行实例化回原来的对象。其关键是如何把对象序列化传输，客户端收到数据后如果解析数据的问题，通过什么方式进行数据的映射，序列化传输的数据映射为对象的问题。对于数据的序列化提出优先使用平台自身提供的序列化方式。

十四、第十六章讲述了乐观离线锁、悲观离线锁、粗粒度锁、隐含锁

1. 乐观离线锁：同时可以多个人编辑数据，对数据提交时冲突的地方进行合并出来类，类似于源代码管理工具TFS的思想；对出来事务时比较弱；其提交数据时进行版本管理，只有版本号一直的数据才能在相同的事务中提交。
2. 悲观离线锁，就是只能有一个人独占文件进行编辑，其他人不能改动，类似于源代码管理工具VSS的思想。悲观离线锁对处理事务比较有优势，并且其是乐观离线锁应用的补充。其有独占写锁，独占读锁、读写锁。
3. 粗粒度锁：就是对一堆的方法调用时把这一堆方法放到同一个锁里面。这一堆方法拥有同一个版本号，那么这一堆方法就共用了这一个锁，叫做共享锁，单锁有2类，所有有乐观共享锁和悲观共享锁。同时其产生了一堆方法(或者对象)，这堆方法拥有一个锁的控制对象，只有锁住这个对象就锁住了所有，这种就是跟对象锁
4. 隐含锁：在某些系统平台中某些方法方法提交了系统锁，或者在对一堆方法的调用时，其中的某个方法加了锁，而其他的方法没有锁，而我们调用的地方根本没有加锁的机会，而无意中产生了锁。

十五、第十七章讲述了客户端会话状态、服务器会话状态、数据库会话状态（注:此会话不是专指session，当然也包括session，而是在交互时需要的一些数据）

1. 客户端会话状态：把会话信息存储到客户端，如存储在Cookie、URL、隐藏域中，如果是复杂对象可以进行序列化后存储。数据存储在客户端不安全，可能存在数据丢失、数据量大时保持困难。
2. 服务器会话状态：把大量交互的数据存储在服务器内存中，而给客户端存储这些数据的一个标识(如NET的sessionid)，当需要这些数据时，客户端出示标识，就可以从服务器内存中读取数据。其容易导致服务器崩溃、集群处理比较困难、占用较大服务器内存。
3. 数据库会话状态：将会话的数据存储到数据库中，把会话数据存储在数据库中，给客户端一个标识（sessiondid），当需要数据时，用标识（sessionid）去数据库中查找数据。集群方便、但是对数据库性能有要去。讲会话数据存储在临时表或者会话信息存储到和业务一起的数据表中，然后加标识位区分会话数据。
4. .NET中对于session可以存储在IIS进程中，服务器内存中（可以是IIS服务器本身的内存中，也可以是另外一台服务器的内存中）、数据库中。

十六、第十八章讲述了入口、映射器、层超类型、分离接口、注册表、值对象、货币、特殊情况、插件、服务桩、记录集

一、通过一步步调查发现发现存储，字段名，等信息的表及表结构如下：
CREATE TABLE [sys].[syscolpars]
(
[id] [int] NOT NULL,
[number] [smallint] NOT NULL,
[colid] [int] NOT NULL,
[name] [sys].[sysname] NULL,--存储列名等的
[xtype] [tinyint] NOT NULL,
[utype] [int] NOT NULL,
[length] [smallint] NOT NULL,
[prec] [tinyint] NOT NULL,
[scale] [tinyint] NOT NULL,
[collationid] [int] NOT NULL,
[status] [int] NOT NULL,
[maxinrow] [smallint] NOT NULL,
[xmlns] [int] NOT NULL,
[dflt] [int] NOT NULL,
[chk] [int] NOT NULL,
[idtval] [varbinary] (64) NULL
) ON [PRIMARY]
GO

字段name就是存储定义表时，表列名名称，等信息的。可见其定义的类型为 [sys].[sysname]，而非常规类型。

通过执行 “exec   sp_help   sysname ”发现其定义的类型为nvarchar （128）为并且不区分大小写，又因为nvarchar 类型是用unicode编码所以我认为只要能识别unicode编码，用中文命列名就不应该有问题，个人建议。

附加Chinese_PRC_CI_AS的解释：

Chinese_PRC_CI_AS不是编码,只是sql中定义的规则

在 Microsoft SQL Server 2000 中，
字符串的物理存储由排序规则控制。排序规则指定表示每个字符的位模式以及存
储和比较字符所使用的规则

前半部份：指UNICODE字符集，Chinese_PRC_指针对大陆简体字UNICODE的排序规则。
排序规则的后半部份即后缀 含义：
  _BIN 二进制排序
  _CI(CS) 是否区分大小写，CI不区分，CS区分
  _AI(AS) 是否区分重音，AI不区分，AS区分  
  _KI(KS) 是否区分假名类型,KI不区分，KS区分
     _WI(WS) 是否区分宽度 WI不区分，WS区分

这个架构基于squid、nginx和lvs等技术，从架构上对bbs进行全面优化和保护，有如下特点：

1、高性能：所有的点击基本上全部由前端缓存负责，提供最快速的处理。

2、高保障度：不需考虑应用程序稳定与否、程序语言是何种、数据库是何种，都能从架构上保证稳定。

3、高可用性：对应用程序的修改达到最简化：在程序的某些地方加入清缓存的语句即可，当然还需要做页面静态化的工作和统计工作。

首先看图，这个图比较大：



这个架构的特点和一些流程的说明：

1、主域名和图片域名分离

域名分离可以使流量分离，缓存策略分离等等，好处诸多。bbs初期一定要做好规划，将图片用另外的域名独立服务，即使没有足够机器，域名也要先分开。另 外，图片服务器可以使用有别于主域名的另一个域名，一个好处是可以减少读取cookie对图片服务器的压力，另一个是提高安全性，避免cookie泄露。

2、使用LVS作为前端、二级代理和数据库的访问入口

使用LVS作为入口，比其他任何一种方式都来得更优质。首先LVS的负载能力很强，因为它工作在网络协议的第4层，使用虚拟ip技术，所以它本身并不担负 任何流量的处理，仅仅是一个封包转发的功能；第二，LVS的配置相对简单而且稳定，一般去调整的几率比较低，也减少了因人为等因素而出现故障；第 三，LVS可以处理任何端口的负载均衡，所以它基本可以做所有服务的负载均衡和容错。在这个架构中，除了处理http的80端口之外，LVS也处理了数据 库mysql的3306端口，在数据库这个应用中是采用的双机热备策略。

3、使用nginx+squid作为最前端的缓存组合

在这个架构中，是最能体现app_nginx_squid_nginx架构的优势的。在这个架构中的bbs运行在缓存上，用户每发布一张帖子，都需要使用 purge指令清除该帖子的缓存，如果是squid在最前端，那么每次发布一张帖子，都需要在所有的squid中调用purge指令，这样在机器比较多的 时候，purge将成为一个巨大的压力。

所以在这里将nginx放在最前端并使用手工url_hash的方式分流，将经常需要purge的帖子页面和列表页面按一个url对应一台squid的策 略，分布到各台squid上，并提供了一台或一组backup的squid，个别squid出现异常时将自动使用backup的机器继续提供一段时间的服 务直到其正常。在这样的架构下，purge就不再是关键问题，因为一个url只会对应到一台机器上，所以purge的时候，后端app_server找到 对应的机器就可以了。

可以看到在前端中还有一台nginx(purge)的机器，这台机器是专用于purge的，只要发送purge指令和需要清除的url到这台机器，就可以 找到相应的服务器并清除缓存了。另外，purge时还需要清理backup机器上的缓存，所以无论前端机器增加到多少，purge指令只会在2台机器上执 行，如果backup机器使用到2-3台，purge指令就会在3-4台机器上执行，仍然在可接受范围之内。

nginx作为前端，另有的好处：

1/使用nginx的日志统计点击量非常方便
2/nginx也可作为缓存，一般可以直接负责favicon.ico和logo等固定的小图片

4、基于nginx的中层代理

nginx中层代理的优势，在：

nginx和squid配合搭建的web服务器前端系统

这篇文章中有解释。

在这个架构中，假如后端的app_server上把帖子页和列表页直接生成了静态页面，那么使用中层代理再做一次url_hash，将可以解决后端 app_server的硬盘容量的压力，但是如果使用到url_hash的话，那做容错就相对麻烦了。所以建议不要采用生成静态页的方式，后端的压力一般 不会非常的大，所以没有必要生成静态页。假如前端squid的命中率实在太低下，造成大量穿透，可以考虑使用二级代理暂顶。

5、基于LVS的数据库双机热备

在这个架构中，因为大量的并发和访问量都由前端的缓存处理掉了，所以后端的mysql主要压力来自于数据的写入，所以压力并不是非常大，并且负载比较稳 定，一般不会随着访问量上升而提高过快，估计目前一台64位的机器，加满内存并使用高速的硬盘，前端负载数亿访问量时数据库都不会出现性能问题。在数据库 这方面应主要考虑故障恢复，因为数据库崩溃的话，按照一般使用备份恢复的做法，耗时很长而且难免丢失数据，是很棘手的问题。使用双机热备的方案，出现故障 时首先可由一台时刻同步着的备用数据库即刻充当主数据库，然后卸下的数据库可以有充分的时间对其进行维修，所以是个很安全有效的办法。

当然，数据库的优化还是要细心做的，参考：

mysql性能的检查和调优方法

细心地调一遍，性能会好很多。

6、图片服务器

图片服务器我在这个架构中没有特别详细的介绍，在大型的bbs系统下，图片常常会出现容灾现象——图片数量严重超过了单台前端服务器容纳能力，导致前端服务器命中率低下。处理容灾问题也是非常棘手的，往后会有更详细的介绍。

7、简单的点击量统计办法

1/使用js的script标签访问另一（台）组服务器的空文件，然后定期向数据库更新
2/在前端的nginx上直接开启日志功能，按需要统计点击量的链接规则进行记录，然后定期更新数据库

转：http://www.oschina.net/question/54100_11155

如果说要对一个站点或者应用程序经常优化，可以说缓存的使用是最快也是效果最明显的方式。一般而言，我们会把一些常用的，或者需要花费大量的资源或时间而产生的数据缓存起来，使得后续的使用更加快速。

  select * from a where a.Status='w' collate Chinese_PRC_CS_AI--区分大小写
--select * from a where a='abCdE' collate    Chinese_PRC_CI_AI--不区分大小写

如何更改SQL SERVER 2000的排序规则

Alter datebase Alter datebase 数据库 Chinese_PRC_BIN 
 
 ALTERTABLE tb 
 ALTERCOLUMN colname nvarchar(100) COLLATE Chinese_PRC_CI_AS 
 --不区分大小写 
ALTERTABLE tb 
 ALTERCOLUMN colname nvarchar(100) COLLATE Chinese_PRC_CS_AS 
 --区分大小写 
 
 
 使用如下命令，可以获得更多的规则： 
 SELECT* 
 FROM ::fn_helpcollations() 


更改数据库排序规则后，表中字段的排序规则仍然没变，如果在企业管理器中在设计表的界面去一个字段一个字段的改太累人了， 
 EXEC sp_configure 'allow updates',1RECONFIGUREWITH OVERRIDE 
 
 update dbo.syscolumns set collationid=65572where collationid=53284 
 
 EXEC sp_configure 'allow updates',0RECONFIGUREWITH OVERRIDE 
 go


修改数据库的排序规则的时候,要确保你的数据库没有任何连接. 
 
 最好在查询分析器中用下面的方法,注意修改数据库名: 
 
 /* 
 关闭用户打开的进程处理 
 */ 
 use master 
 go 
 
 ifexists (select*from dbo.sysobjects where id =object_id(N'[dbo].[p_killspid]') andOBJECTPROPERTY(id, N'IsProcedure') =1) 
 dropprocedure[dbo].[p_killspid] 
 GO 
 
 createproc p_killspid 
 @dbnamevarchar(200) --要关闭进程的数据库名 
as 
 declare@sqlnvarchar(500) 
 declare@spidnvarchar(20) 
 
 declare #tb cursorfor 
 select spid=cast(spid asvarchar(20)) from master..sysprocesses where dbid=db_id(@dbname) 
 open #tb 
 fetchnextfrom #tb into@spid 
 while@@fetch_status=0 
 begin 
 exec('kill '+@spid) 
 fetchnextfrom #tb into@spid 
 end 
 close #tb 
 deallocate #tb 
 go 
 
 --关闭用户连接 
exec p_killspid '数据库名' 
 go 
 
 --修改排序规则 
Alter datebase Alter datebase 数据库名 Chinese_PRC_BIN 

转：http://hi.baidu.com/solorez/blog/item/7d1a2b973fc7a36955fb9631.html