SQL Server 2000与2005的比较

自动编号：设字段类型为：int ，然后列属性中 （是标识）选是，标识种子选1。

    用varchar(max)代替text。varchar的最大长度为8000，但是varchar(max)则可以存储多达2G的数据，因此其作用相当 于SQL 2000中的text。但是微软可能会后续的SQL Server版本中移除text类型，从现在就应该用varchar(max) 来代替text。

    用nvarchar(max)代替ntext，用binary(max)代替image.

    为XML数据选择xml类型。在SQL Server 2005中，为XML数据添加了相应的数据类型，因此存储XML数据的列不需要用 varchar(max)或nvarchar(max)，而应当用xml数据类型，以利用T-SQL中专门针对xml数据列的新命令，以及针对xml列的 索引。

 

易混淆的数据类型
(1)char、varchar、text和nchar、nvarchar、ntext
char和varchar的长度都在1到8000之间，它们的区别在于char是定长字符数据，而varchar是变长字符数据。所谓定长就是长度固定 的，当输入的数据长度没有达到指定的长度时将自动以英文空格在其后面填充，使长度达到相应的长度；而变长字符数据则不会以空格填充。 text存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。
后面三种数据类型和前面的相比，从名称上看只是多了个字母"n"，它表示存储的是Unicode数据类型的字符。写过程序的朋友对Unicode应该很了 解。字符中，英文字符只需要一个字节存储就足够了，但汉字众多，需要两个字节存储，英文与汉字同时存在时容易造成混乱，Unicode字符集就是为了解决 字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之 间。和char、varchar比较：nchar、nvarchar则最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存 储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数 量上有些损失。

(2)datetime和smalldatetime
datetime：从1753年1月1日到9999年12月31日的日期和时间数据，精确到百分之三秒。
smalldatetime：从1900年1月1日到2079年6月6日的日期和时间数据，精确到分钟。

(3)bitint、int、smallint、tinyint和bit
bigint：从-2^63(-9223372036854775808)到2^63-1(9223372036854775807)的整型数据。
int：从-2^31(-2,147,483,648)到2^31-1(2,147,483,647)的整型数据。
smallint：从-2^15(-32,768)到2^15-1(32,767)的整数数据。
tinyint：从0到255的整数数据。
bit：1或0的整数数据。

(4)decimal和numeric
这两种数据类型是等效的。都有两个参数：p（精度）和s（小数位数）。p指定小数点左边和右边可以存储的十进制数字的最大个数，p必须是从 1到38之间的值。s指定小数点右边可以存储的十进制数字的最大个数，s必须是从0到p之间的值，默认小数位数是0。

(5)float和real
float：从-1.79^308到1.79^308之间的浮点数字数据。
real：从-3.40^38到3.40^38之间的浮点数字数据。在SQL Server中，real的同义词为float(24)。

 

关于SQL SERVER 2005 与SQL SERVER 2000比较

这个题目太大了,这里只能大体介绍一下，细节方面还需大家共同研究！希望能使大家对SQL SERVER 2005 快速入手,另外sql server 2005 的界面风格有越来越像 .net了,赶快安装一个感受一下吧!进去之后不要再去找查询分析器了,它和企业管理器都被集成在”Microsoft SQL Server Management studio”了,这个工具占内存较大80M多(再加上sql server 的实例进程80M,就160M了),而以前的企业管理器只需20M左右,加上sql server 的实例进程10M多一共才30M多.有得必有失~!

hacker at 2006/9/29
一、数据库设计方面
1、字段类型。
SQL Server 2005引入了一系列 新的被称为MAX的数据类型。这是VARCHAR，NVARCHAR和VARBINARY类型的扩展，这几种类型 以前被限制在8000字节以下。MAX可以容纳高达2GB的数据，与TEXT和IMAGE一样。
可以使用字符串函数对CLOB类型进行操作。但是这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？是否碎片会引发效率问题？这都是需要进一步探讨的东西。
数据类型
Sql server2000 Sql server2005
text 最大2GB varchar(max) 最大2GB(相当于oracle中的CLOB类型)
ntext 最大2GB nvarchar(max) 最大2GB
image 最大2GB varbinary(max) 最大2GB（代替image也让SQL Server的字段类型更加简洁统一）
无 XML XML 数据被作为二进制大型对象 (BLOB) 存储于内部，可有效地进行重新分析和压缩
其它数据类型保持不变。
2、外键的级联更能扩展
新版本中外键级联加入了SET NULL 和 SET DEFAULT 属性，能够提供能好的级联设置。(有点像oracle了)语法如下(引用sql server 2005 help来说明):
CREATE TABLE 和 ALTER TABLE 语句的 REFERENCES 子句支持 ON DELETE 和 ON UPDATE 子句：
? [ ON DELETE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
? [ ON UPDATE { NO ACTION | CASCADE | SET NULL | SET DEFAULT } ]
如果没有指定 ON DELETE 或 ON UPDATE，则默认为 NO ACTION。
NO ACTION
指定如果试图删除/修改某一行，而该行的键被其他表的现有行中的外键所引用，则产生错误并回滚 DELETE/UPDATE语句。
CASCADE、SET NULL 和 SET DEFAULT
允许通过删除或更新键值来影响指定具有外键关系的表，这些外键关系可追溯到在其中进行修改的表。如果为目标表也定义了级联引用操作，那么指定的级联操作也将应用于删除或更新的那些行。不能为具有 timestamp 列的外键或主键指定 CASCADE。
ON DELETE CASCADE
指定如果试图删除某一行，而该行的键被其他表的现有行中的外键所引用，则也将删除所有包含那些外键的行。
ON UPDATE CASCADE
指定如果试图更新某一行中的键值，而该行的键值被其他表的现有行中的外键所引用，则组成外键的所有值也将更新到为该键指定的新值。 (如果 timestamp 列是外键或被引用键的一部分，则不能指定 CASCADE。 )
ON DELETE SET NULL
指定如果试图删除某一行，而该行的键被其他表的现有行中的外键所引用，则组成被引用行中的外键的所有值将被设置为 NULL。目标表的所有外键列必须可为空值，此约束才可执行。
ON DELETE SET NULL
指定如果试图更新某一行，而该行的键被其他表的现有行中的外键所引用，则组成被引用行中的外键的所有值将被设置为 NULL。目标表的所有外键列必须可为空值，此约束才可执行。
ON DELETE SET DEFAULT
指定如果试图删除某一行，而该行的键被其他表的现有行中的外键所引用，则组成被引用行中的外键的所有值将被设置为它们的默认值。目标表的所有外键列必须具 有默认值定义，此约束才可执行。如果某个列可为空值，并且未设置显式的默认值，则会使用 NULL 作为该列的隐式默认值。因 ON DELETE SET DEFAULT 而设置的任何非空值在主表中必须有对应的值，才能维护外键约束的有效性。
ON UPDATE SET DEFAULT
指定如果试图更新某一行，而该行的键被其他表的现有行中的外键所引用，则组成被引用行中的外键的所有值将被设置为它们的默认值。目标表的所有外键列必须具 有默认值定义，此约束才可执行。如果某个列可为空值，并且未设置显式的默认值，则会使用 NULL 作为该列的隐式默认值。因 ON UPDATE SET DEFAULT 而设置的任何非空值在主表中必须有对应的值，才能维护外键约束的有效性。

3、索引附加字段
即在索引中存储一些常用字段以提高查询速度,这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。在实验环境中会比映射到表中提高30%左右的效率。例:
CREATE INDEX ix_CustomerPostalcode
On Sales.Customer(PostalCode)
INCLUDE (AddressLine1,AddressLine2,City)
索引会提高查询(select)语句的性能,但建有大量索引会影响 INSERT、UPDATE 和 DELETE 语句的性能，因为在表中的数据更改时，所有索引都须进行适当的调整。
4、计算字段的持久化
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。
使用 ORDER 排序和虚拟字段 虚拟字段完成的是类似 自增长 ID 的任务
select identity(int,1,1) ID ,hymc into #temp
from hybm
order by hymc
(注: 在ORACLE中，语句: select rownum from USERTABLE order by USERNAME; 得到的rownum还是没有排过序时的ROWNUM，根本不是已经排过序的ROWNUM。也就是说，有没有ORDER BY一个样。)
5、分区表
分区表是个亮点！从分区表也能看出微软要做大作强SQL Server的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQL Server2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。但是需要注意的一 点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚 集索引时，分区表会自动变为非分区表。这一点很让我纳闷。如果你觉得我的非分区索引无法对起子分区，你可以提醒我一下呀！没有任何的提醒，直接就变成了非 分区表。不知道这算不算一个bug。大家也可以试试。
分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查 询，效率会低于未分区表的相同语句。但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）
6、CLR类型
微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。但是作了些试验， 发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重 的系统性能问题！
其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！还不是性能有问题！否则面向对象的数据库早就实现了！
建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。