一、數(shù)據(jù)庫(kù)設(shè)計(jì)方面

1、字段類型。

varchar(max) varchar(max)類型的引入大大的提高了編程的效率，可以使用字符串函數(shù)對(duì)CLOB類型進(jìn)行操作，這是一個(gè)亮點(diǎn)。但是這就引發(fā)了對(duì)varchar和char效率討論的老問(wèn)題。到底如何分配varchar的數(shù)據(jù)，是否會(huì)出現(xiàn)大規(guī)模的碎片？是否碎片會(huì)引發(fā)效率問(wèn)題？這都是需要進(jìn)一步探討的東西。

varbinary(max)代替image也讓SQL   Server的字段類型更加簡(jiǎn)潔統(tǒng)一。

XML字段類型更好的解決了XML數(shù)據(jù)的操作。XQuery確實(shí)不錯(cuò)，但是個(gè)人對(duì)其沒好感。（CSDN的開發(fā)者應(yīng)該是相當(dāng)?shù)氖炝耍。?/P>

2、外鍵的級(jí)聯(lián)更能擴(kuò)展

可能大部分的同行在設(shè)計(jì)OLTP系統(tǒng)的時(shí)候都不愿意建立外鍵，都是通過(guò)程序來(lái)控制父子數(shù)據(jù)的完整性。但是再開發(fā)調(diào)試階段和OLAP環(huán)境中，外鍵是可以建立的。新版本中加入了SET   NULL   和   SET   DEFAULT   屬性，能夠提供能好的級(jí)聯(lián)設(shè)置。

3、索引附加字段

這是一個(gè)不錯(cuò)的新特性。雖然索引的附加字段沒有索引鍵值效率高，但是相對(duì)映射到數(shù)據(jù)表中效率還是提高了很多。我做過(guò)試驗(yàn)，在我的實(shí)驗(yàn)環(huán)境中會(huì)比映射到表中提高30%左右的效率。

4、計(jì)算字段的持久化

原來(lái)的計(jì)算字段其實(shí)和虛擬字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了計(jì)算字段的持久化，這就提高了查詢的性能，但是會(huì)加重insert和update的負(fù)擔(dān)。OLTP慎用。OLAP可以大規(guī)模使用。

5、分區(qū)表

分區(qū)表是個(gè)亮點(diǎn)！從分區(qū)表也能看出微軟要做大作強(qiáng)SQL   Server的信心。資料很多，這里不詳細(xì)說(shuō)。但是重點(diǎn)了解的是：現(xiàn)在的SQL   Server2005的表，都是默認(rèn)為分區(qū)表的。因?yàn)樗С只瑒?dòng)窗口的這個(gè)特性。這種特性對(duì)歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)的處理是很有幫助的。

但是需要注意的一點(diǎn)，也是我使用過(guò)程中發(fā)現(xiàn)的一個(gè)問(wèn)題。在建立function-> schema-> table后，如果在現(xiàn)有的分區(qū)表上建立沒有顯式聲明的聚集索引時(shí)，分區(qū)表會(huì)自動(dòng)變?yōu)榉欠謪^(qū)表。這一點(diǎn)很讓我納悶。如果你覺得我的非分區(qū)索引無(wú)法對(duì)起子分區(qū)，
你可以提醒我一下呀！沒有任何的提醒，直接就變成了非分區(qū)表。不知道這算不算一個(gè)bug。大家也可以試試。

分區(qū)表效率問(wèn)題肯定是大家關(guān)心的問(wèn)題。在我的試驗(yàn)中，如果按照分區(qū)字段進(jìn)行的查詢（過(guò)濾）效率會(huì)高于未分區(qū)表的相同語(yǔ)句。但是如果按照非分區(qū)字段進(jìn)行查詢，效率會(huì)低于未分區(qū)表的相同語(yǔ)句。但是隨著數(shù)據(jù)量的增大，這種成本差距會(huì)逐漸減小，趨于相等。（500萬(wàn)數(shù)量級(jí)只相差10%左右）

6、CLR類型

微軟對(duì)CLR作了大篇幅的宣傳，這是因?yàn)閿?shù)據(jù)庫(kù)產(chǎn)品終于融入.net體系中。最開始我們也是狂喜，感覺對(duì)象數(shù)據(jù)庫(kù)的一些概念可以實(shí)現(xiàn)了。但是作了些試驗(yàn)，發(fā)現(xiàn)使用CLR的存儲(chǔ)過(guò)程或函數(shù)在達(dá)到一定的閥值的時(shí)候，系統(tǒng)性能會(huì)呈指數(shù)級(jí)下滑！這是非常危險(xiǎn)的！只使用幾個(gè)可能沒有問(wèn)題，當(dāng)一旦大規(guī)模使用會(huì)造成嚴(yán)重的系統(tǒng)性能問(wèn)題！

其實(shí)可以做一下類比，Oracle等數(shù)據(jù)庫(kù)產(chǎn)品老早就支持了java編程，而且提供了java池參數(shù)作為用戶配置接口。但是現(xiàn)在有哪些系統(tǒng)大批使用了java存儲(chǔ)過(guò)程？！連Oracle自己的應(yīng)用都不用為什么？！還不是性能有問(wèn)題！否則面向?qū)ο蟮臄?shù)據(jù)庫(kù)早就實(shí)現(xiàn)了！

建議使用CLR的地方一般是和應(yīng)用的復(fù)雜程度或操作系統(tǒng)環(huán)境有很高的耦合度的場(chǎng)景。如你想構(gòu)建復(fù)雜的算法，并且用到了大量的指針和高級(jí)數(shù)據(jù)模型?；蛘呤且筒僮飨到y(tǒng)進(jìn)行Socket通訊的場(chǎng)景。否則建議慎重！

7、索引視圖

索引視圖2k就有。但是2005對(duì)其效率作了一些改進(jìn)但是schema.viewname的作用域真是太限制了它的應(yīng)用面。還有一大堆的環(huán)境參數(shù)和種種限制都讓人對(duì)它有點(diǎn)卻步。

8、語(yǔ)句和事務(wù)快照

語(yǔ)句級(jí)快照和事務(wù)級(jí)快照終于為SQL   Server的并發(fā)性能帶來(lái)了突破。個(gè)人感覺語(yǔ)句級(jí)快照大家應(yīng)該應(yīng)用。事務(wù)級(jí)快照，如果是高并發(fā)系統(tǒng)還要慎用。如果一個(gè)用戶總是被提示修改不成功要求重試時(shí)，會(huì)殺人的！

9、數(shù)據(jù)庫(kù)快照

原理很簡(jiǎn)單，對(duì)要求長(zhǎng)時(shí)間計(jì)算某一時(shí)間點(diǎn)的報(bào)表生成和防用戶操作錯(cuò)誤很有幫助。但是比起Oracle10g的閃回技術(shù)還是細(xì)粒度不夠。可惜！

10、Mirror
Mirror可以算是SQL   Server的Data   guard了。但是能不能被大伙用起來(lái)就不知道了。

二、開發(fā)方面

1、Ranking函數(shù)集

其中最有名的應(yīng)該是row_number了。這個(gè)終于解決了用臨時(shí)表生成序列號(hào)的歷史，而且SQL   Server2005的row_number比Oracle的更先進(jìn)。因?yàn)樗袿rder   by集成到了一起，不用像Oracle那樣還要用子查詢進(jìn)行封裝。但是大家注意一點(diǎn)。如下面的例子：

select   ROW_NUMBER()   OVER   (order   by   aa)
from   tbl
order   by   bb

會(huì)先執(zhí)行aa的排序，然后再進(jìn)行bb的排序。

可能有的朋友會(huì)抱怨集成的order   by，其實(shí)如果使用ranking函數(shù),Order   by是少不了的。如果擔(dān)心Order   by會(huì)影響效率，可以為order   by的字段建立聚集索引，查詢計(jì)劃會(huì)忽略order   by   操作（因?yàn)楸緛?lái)就是排序的嘛）。

2、top
可以動(dòng)態(tài)傳入?yún)?shù)，省卻了動(dòng)態(tài)SQL的拼寫。

3、Apply
對(duì)遞歸類的樹遍歷很有幫助。

4、CTE
個(gè)人感覺這個(gè)真是太棒了！閱讀清晰，非常有時(shí)代感。

5、try/catch
代替了原來(lái)VB式的錯(cuò)誤判斷。比Oracle高級(jí)不少。

6、pivot/unpivot
個(gè)人感覺沒有case直觀。而且默認(rèn)的第三字段（還可能更多）作為group   by字段很容易造成新手的錯(cuò)誤。

三、DBA管理方面

1、數(shù)據(jù)庫(kù)級(jí)觸發(fā)器

記得在最開始使用2k的時(shí)候就要用到這個(gè)功能，可惜2k沒有，現(xiàn)在有了作解決方案的朋友會(huì)很高興吧。

2、多加的系統(tǒng)視圖和實(shí)時(shí)系統(tǒng)信息

這些東西對(duì)DBA挑優(yōu)非常有幫助，但是感覺粒度還是不太細(xì)。

3、優(yōu)化器的改進(jìn)

一直以來(lái)個(gè)人感覺SQL   Server的優(yōu)化器要比Oracle的聰明。SQL2005的更是比2k聰明了不少。（有次作試驗(yàn)發(fā)現(xiàn)有的語(yǔ)句在200萬(wàn)級(jí)時(shí)還比50萬(wàn)級(jí)的相同語(yǔ)句要快show_text的一些提示沒有找到解釋。一直在奇怪。）

例子：

oxJob(JobID)   jobid為聚集索引  
  oxOrder(OrderID,JobID)   兩個(gè)字段都分別建有索引  
  
  CREATE   VIEW   dbo.vw_test  
  
  AS  
  
  select   jobid,   operationid   =   jobid   from   dbo.oxjob    
  union   all  
  select   jobid,   orderid   as   operationid   from   dbo.oxorder  
  
  查詢：  
  select   jobid   from   vw_test   where   operationid   =   @id  
       
  
  以下是測(cè)試script:  
  CREATE   TABLE   [dbo].[C]   (  
  [a]   [varchar]   (50)   NOT   NULL   ,  
     [varchar]   (50)   NULL    
  )   ON   [PRIMARY]  
  GO  
  
  CREATE   TABLE   [dbo].[D]   (  
  [a]   [varchar]   (50)   NOT   NULL   ,  
  [c]   [varchar]   (50)   NULL    
  )   ON   [PRIMARY]  
  GO  
  
  ALTER   TABLE   [dbo].[C]   WITH   NOCHECK   ADD    
  CONSTRAINT   [PK_C]   PRIMARY   KEY     CLUSTERED    
  (  
  [a]  
  )     ON   [PRIMARY]    
  GO  
  
  ALTER   TABLE   [dbo].[D]   WITH   NOCHECK   ADD    
  CONSTRAINT   [PK_D]   PRIMARY   KEY     CLUSTERED    
  (  
  [a]  
  )     ON   [PRIMARY]    
  GO  
  
    CREATE     INDEX   [IX_C_b]   ON   [dbo].[C]()   ON   [PRIMARY]  
  GO  

  CREATE   VIEW   dbo.vw_Test  
  AS  
  SELECT   a,b   from   C  
  union   all  
  select   a,a   from   D 

CREATE   VIEW   dbo.vw_Test  
  AS  
  SELECT   a,b   from   C  
  union   all  
  select   a,a   from   D  

4、profiler的新事件觀察
這一點(diǎn)很好的加強(qiáng)了profiler的功能。但是提到profiler提醒大家注意一點(diǎn)。windows2003要安裝sp1補(bǔ)丁才能啟動(dòng)profiler。否則點(diǎn)擊沒有反應(yīng)。

5、sqlcmd

習(xí)慣敲命令行的朋友可能會(huì)爽一些。但是功能有限。適合機(jī)器跑不動(dòng)SQL   Server   Management   Studio的朋友使用。

四、遺憾

1、登陸的控制

始終遺憾SQL   Server的登陸無(wú)法分配CPU/內(nèi)存占用等指標(biāo)數(shù)。如果你的SQL   Server給別人分配了一個(gè)只可以讀幾個(gè)表的權(quán)限，而這個(gè)家伙瘋狂的死循環(huán)進(jìn)行連接查詢，會(huì)給你的系統(tǒng)帶來(lái)很大的負(fù)擔(dān)。而SQL   Server如果能像Oracle一樣可以為登陸分配如：5%的cpu，10%的內(nèi)存。就可以解決這個(gè)漏洞。

2、數(shù)據(jù)庫(kù)物理框架沒有變動(dòng)

undo和redo都放在數(shù)據(jù)庫(kù)得transaction中，個(gè)人感覺是個(gè)敗筆。如果說(shuō)我們?cè)谠O(shè)計(jì)數(shù)據(jù)庫(kù)的時(shí)候考慮分多個(gè)數(shù)據(jù)庫(kù)，可能能在一定程度上避免 I/O效率問(wèn)題。但是同樣會(huì)為索引視圖等應(yīng)用帶來(lái)麻煩。看看行級(jí)和事務(wù)級(jí)的快照數(shù)據(jù)放在tempdb中，就能感覺到目前架構(gòu)的尷尬。

3、還是沒有邏輯備份
備份方面可能還是一個(gè)老大難的問(wèn)題。不能單獨(dú)備份幾個(gè)表總是感覺不爽。靈活備份的問(wèn)題不知道什么時(shí)候才能解決。

4、SSIS(DTS)太復(fù)雜了

SQL   Server的異構(gòu)移植功能個(gè)人感覺最好了。（如果對(duì)比過(guò)SQL   Server的鏈接服務(wù)器和Oracle的透明網(wǎng)關(guān)的朋友會(huì)發(fā)現(xiàn)SQL   Server的sp_addlinkedserver(openquery)異構(gòu)數(shù)據(jù)庫(kù)系列比Oracle真是強(qiáng)太多了。）

以前的DTS輕盈簡(jiǎn)單。但是現(xiàn)在的SSIS雖然功能強(qiáng)大了很多，但是總是讓人感覺太麻煩?？纯凑搲性儐?wèn)SSIS的貼子就知道。做的功能太強(qiáng)大了，往往會(huì)有很多用戶不會(huì)用了。