對於程式中的string型字段，sqlserver中有char、varchar、nchar、nvarchar四種型別來對應（暫時不考慮text和ntext），開建立資料庫中，對這四種型別往往比較模糊，這裡做一下對比。
所謂定長就是長度固定的，當輸入的資料長度沒有達到指定的長度時將自動以英文空格在其後面填充，使長度達到相應的長度；有var字首的，表示是實際儲存空間是變長的，比如varchar,nvarchar變長字元資料則不會以空格填充，比較例外的是，text儲存的也是可變長。
資料庫中，英文本元只需要乙個位元組儲存就足夠了，但漢字和其他眾多非英文本元，則需要兩個位元組儲存。如果英文與漢字同時存在，由於占用空間數不同，容易造成混亂，導致讀取出來的字串是亂碼。unicode字符集就是為了解決字符集這種不相容的問題而產生的，它所有的字元都用兩個位元組表示，即英文本元也是用兩個位元組表示。而字首n就表示unicode字元，比如nchar,nvarchar，這兩種型別使用了unicode字符集。
char，varchar
最多8000個英文，4000個漢字
nchar，nvarchar
可儲存4000個字元，無論英文還是漢字
如果資料量非常大，又能100%確定長度且儲存只是ansi字元，那麼char能確定長度又不一定是ansi字元或者，那麼用nchar；對於超大資料，如文章內容，使用ntext，其他的通用nvarchar
char儲存定長資料很方便，char欄位上的索引效率級高，比如定義char(10)，那麼不論你儲存的資料是否達到了10個位元組，都要占去10個位元組的空間。
儲存變長資料，但儲存效率沒有char高,如果乙個字段可能的值是不固定長度的，我們只知道它不可能超過10個字元，把它定義為 varchar(10)是最合算的。varchar型別的實際長度是它的值的實際長度+1。為什麼"+1"呢？這乙個位元組用於儲存實際使用了多大的長度。
從空間上考慮，用varchar合適；從效率上考慮，用char合適，關鍵是根據實際情況找到權衡點。
text儲存可變長度的非unicode資料，最大長度為2^31-1(2,147,483,647)個字元。
這三種從名字上看比前面三種多了個"n"。和char、varchar比較起來，nchar、nvarchar最多儲存4000個字元，不論是英文還是漢字；而char、varchar最多能儲存8000個英文，4000個漢字。可以看出使用nchar、nvarchar資料型別時不用擔心輸入的字元是英文還是漢字，較為方便，但在儲存英文時數量上有些損失。
所以一般來說，如果含有中文字元，用nchar/nvarchar，如果純英文和數字，用char/varchar。
機房重構 SQl之儲存過程
上篇部落格介紹了sql檢視的使用，這篇部落格通過內容和例項應用來簡單介紹一下儲存過程。在機房重構的過程中，犯了個大忌 資料庫設計在重構過程被修改了 所以影響了乙個功能的實現，就又重新敲了一下機房收費系統退卡功能。正如 塞翁失馬，焉知非福 純三層的 實現變成了利用儲存過程之後的完美實現。期間的磕磕絆絆...
機房重構 SQL語句已終止
在下機將消費時間寫入資料庫時，出現了乙個沒有遇到過的錯誤，用了將近一下午的時間才改正過來，其實出錯的原因也很簡單。語句已終止 首先想到的是自己沒有那個能力將更新語句寫成終止語句吧！思維往這個方向偏，就忽略了本身導致問題的原因。思維越來越偏，甚至懷疑是自己寫的sql語句導致資料庫死迴圈了，真是腦洞大開...
機房重構之組合查詢
組合查詢，不好弄，因為需要有模板模式。不過經過問別人看部落格之後，也算是理解著弄完了。只是弄完了不行啊，得總結啊，那就總結吧。我理解的模板方法就是先建立乙個父模板，然後讓子類來繼承父類，使用父類的功能。public virtual void todgv entity.groupcheck group...