SQL 2005 得到增強的功能

  1、外來鍵的級聯更能擴充套件 新版本中外來鍵級聯加入了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 而設定的任何非空值在主表中必須有對應的值，才能維護外來鍵約束的有效性。

  2、索引附加欄位 即在索引中儲存一些常用欄位以提高查詢速度,這是一個不錯的新特性。雖然索引的附加欄位沒有索引鍵值效率高，但是相對對映到資料表中效率還是提高了很多。在實驗環境中會比對映到表中提高30%左右的效率。
 
  例: CREATE INDEX ix_CustomerPostalcode On Sales.Customer(PostalCode) INCLUDE (AddressLine1,AddressLine2,City) 索引會提高查詢(select)語句的效能,但建有大量索引會影響 INSERT、UPDATE 和 DELETE 語句的效能，因為在表中的資料更改時，所有索引都須進行適當的調整。

  3、計算欄位的持久化 原來的計算欄位其實和虛擬欄位很像。只是管理方面好了而已，效能方面提高不多。但是SQL2005提供了計算欄位的持久化，這就提高了查詢的效能，但是會加重insert和update的負擔。

   4、分割槽表 分割槽表是個亮點！從分割槽表也能看出微軟要做大作強SQL Server的信心。資料很多，這裡不詳細說。但是重點了解的是：現在的SQL Server2005的表，都是預設為分割槽表的。因為它要支援滑動視窗的這個特性。這種特性對歷史資料和實時資料的處理是很有幫助的。

  但是需要注意的一 點，也是我使用過程中發現的一個問題。在建立function->schema->table後，如果在現有的分割槽表上建立沒有顯式宣告的聚 集索引時，分割槽表會自動變為非分割槽表。這一點很讓我納悶。如果你覺得我的非分割槽索引無法對起子分割槽，你可以提醒我一下呀！沒有任何的提醒，直接就變成了非 分割槽表。不知道這算不算一個bug。大家也可以試試。
　
  分割槽表效率問題肯定是大家關心的問題。在我的試驗中，如果按照分割槽欄位進行的查詢（過濾）效率會高於未分割槽表的相同語句。但是如果按照非分割槽欄位進行查 詢，效率會低於未分割槽表的相同語句。但是隨著資料量的增大，這種成本差距會逐漸減小，趨於相等。（500萬數量級只相差10%左右）

   5、CLR型別 微軟對CLR作了大篇幅的宣傳，這是因為資料庫產品終於融入.net體系中。最開始我們也是狂喜，感覺物件資料庫的一些概念可以實現了。但是作了些試驗， 發現使用CLR的儲存過程或函式在達到一定的閥值的時候，系統效能會呈指數級下滑！這是非常危險的！只使用幾個可能沒有問題，當一旦大規模使用會造成嚴重 的系統效能問題！

  其實可以做一下類比，Oracle等資料庫產品老早就支援了java程式設計，而且提供了java池引數作為使用者配置介面。但是現在有哪些系統大批使用了java儲存過程？！連Oracle自己的應用都不用為什麼？！還不是效能有問題！否則物件導向的資料庫早就實現了！ 建議使用CLR的地方一般是和應用的複雜程度或作業系統環境有很高的耦合度的場景。如你想構建複雜的演算法，並且用到了大量的指標和高階資料模型。或者是要和作業系統進行Socket通訊的場景。否則建議慎重！

  6、索引檢視 索引檢視2k就有。但是2005對其效率作了一些改進但是schema.viewname的作用域真是太限制了它的應用面。還有一大堆的環境引數和種種限制都讓人對它有點卻步。

  7、語句和事務快照 語句級快照和事務級快照終於為SQL Server的併發效能帶來了突破。個人感覺語句級快照大家應該應用。事務級快照，如果是高併發系統還要慎用。如果一個使用者總是被提示修改不成功要求重試時，會殺人的！

  8、資料庫快照 原理很簡單，對要求長時間計算某一時間點的報表生成和防使用者操作錯誤很有幫助。但是比起Oracle10g的閃回技術還是細粒度不夠。可惜！

  例子： CREATE DATABASE demo2 GO USE demo2 ALTER DATABASE demo2 SET allow_snapshot_isolation ON --啟動快照功能 CREATE TABLE test ( tid INT NOT NULL primary key, tname VARCHAR(50) NOT NULL ) INSERT INTO test VALUES(1,'version1') INSERT INTO test VALUES(2,'version2') --連線一 USE demo2 BEGIN TRAN UPDATE test SET tname='version3' WHERE tid=2 SELECT * FROM test --連線二 USE demo2 SET transaction isolation level snapshot SELECT * FROM test

  9、Mirror Mirror可以算是SQL Server的Data guard了。具說它切換速度可以達到秒級

 

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-464485/，如需轉載，請註明出處，否則將追究法律責任。