三級數(shù)據(jù)庫：SQLServer存儲多語言數(shù)據(jù)幾種方法

　　本文概述了在數(shù)據(jù)庫設計中，如何處理多國語言的問題，這里的多國語言是指諸如這樣的業(yè)務：在ERP軟件中，我們在填寫客戶名稱時，除了需要填寫客戶的中文名稱，還需要填寫他的英文名稱。 一般的，如果是普通的項目型軟件，就比較簡單了，你只需要設計出固定的 ChineseName和EnglishName字段就可以了。本文并不討論這種形式，而是討論在大型平臺化的ERP軟件中如何實現(xiàn)通用化的多語言存儲和讀取。

　　子表方式

　　第一種方式是建立一張子表，U9大概就是這個樣子，你需要注意的是，每一個實體如果包含多語言字段，都會出現(xiàn)以_Trl為后綴的表。也許你會覺得麻煩，其實不然，這些都是平臺在后臺自動處理了，你僅僅需要標記這個字段是多語言字段就可以了。

　　從理論上來說，他的存儲是最符合數(shù)據(jù)庫設計原則的，不管你的系統(tǒng)使用多少語言，數(shù)據(jù)庫結(jié)構(gòu)是不變的。但是我總覺得查詢起來SQL會比較復雜，雖然這事平臺也會幫助你完成。我在想，如果我要一個多語言策略如何實現(xiàn)呢?多語言策略的例子：如果此字段沒有對應的繁體中文，取簡體中文，如果還沒有，取默認的語言內(nèi)容。那么在一個SQL中如何實現(xiàn)呢?

　　不管怎么樣，至少我不喜歡這種。

　　多字段模式

　　恩?這是哪門子設計?和我上面講的項目型設計不是一樣嗎?

　　數(shù)據(jù)結(jié)構(gòu)是一樣的，唯一的區(qū)別是通過ORM屏蔽了數(shù)據(jù)庫的結(jié)構(gòu)，在設計實體時，你僅僅設計了Name字段，其類型是“多語言類型”，然后在客戶那里初始化時，客戶可以決定采用多少種語言，然后ORM在后臺自動添加這些列。

　　這是我希望的設計，因為他足夠的簡潔，任何人都可以非常方便的寫出SQL語言。而且執(zhí)行起來一定是最高效的。而且實現(xiàn)上面說的取值策略也很容易，只需要實現(xiàn)編排好多個嵌套的IIF函數(shù)就是了。

　　缺點呢?當然有，首先冗余很大，即使沒有填寫對應的英文，一樣要占用一個空間。其次，如果客戶發(fā)神經(jīng)，一下子選擇了十幾個語言，然后發(fā)現(xiàn)他并不需要，又想刪除掉?那么我需要檢查數(shù)據(jù)庫的所有相關字段是否全部沒有數(shù)據(jù)，才能決定可以刪除這個語言并刪除所有相關的字段。這是個問題。

　　XML字段

　　這種方式我就不畫圖了，很簡單，還是只有一個字段Name，不過數(shù)據(jù)類型不是nvarchar,而是把定義成XML類型，這是SQLServer2005新增的類型，我們可以在此字段存儲諸如下面這樣的數(shù)據(jù)：

　　<items>
　　<item　lng=""　value="默認"　/>
　　<item　lng="CHS"　value="中文"　/>
　　<item　lng="EN"　value="English"　/>
　　</items>

　　那么在SQL中怎么輸出對應的中文內(nèi)容呢?很簡單：

　　Select　EmployeeId,Name.value(’(/items/item[@lng="CHS"]/@value)[1]’,’nvarchar(max)’)　FROM　Employees

　　很簡單，我喜歡。

　　不過有人可能會說，其實沒有xml類型前，我就已經(jīng)使用nvarchar來實現(xiàn)了，使用一個自定義函數(shù)一樣可以解決(使用諸如：/en/english /chs/中文的方式存儲)。但是我認為字符串方式處理并不完美，主要表現(xiàn)在你必須自己小心處理特殊字符，否則很容易亂套。使用XML類型的話數(shù)據(jù)庫會處理這些。另外，SQL Server對XML類型的查詢有優(yōu)化處理，比起SQL自定義函數(shù)運行的速度要快的多。而且，我相信，以后SQL Server對XML的支持會越來越好。