2011-06-14 102 views
5

我有一個爲英國市場編寫的應用程序,目前僅支持英語(英國),客戶希望將部分應用程序部署到非英國站點並將數據同步回英國總部。翻譯數據庫字符串

我可以使用資源文件和本地文化信息轉換應用程序標籤和消息,但想知道如何轉換數據庫綁定數據。

E.G. 這裏是總部基於表格

tblFault 
ID ; Description 
1 ; Not Functional 
2 ; Build Fault 
3 ; Leak 
4 ; Aesthetics 
5 ; Testing 

如果我是將數據轉換到非英國語言我可以只更換的說明,但如果數據是unsyncronised這會引起一些問題?

我是否應該用另一列擴展表以獲取其他語言,然後使用當地文化改變選擇?

tblFault 
ID ; Description-EN ; Descrption-US ; Description-DE etc 
1 ; Not Functional ;    ; 
2 ; Build Fault ;    ; 
3 ; Leak   ;    ; 
4 ; Aesthetics  ;    ; 
5 ; Testing  ;    ; 

你會推薦什麼方法?

感謝

菲爾

回答

5

既然你有一個1:故障,並對其n之間的關係,在乾淨的解決方案是創建一個子表:

tblFault 
-------- 

FaultID ; some other fields 
     1 ; ... 
     2 ; ... 
     3 ; ... 
     4 ; ... 
     5 ; ... 


tblFault_Description 
-------------------- 

FaultID ; lang ; Description 
     1 ; en ; Not Functional 
     1 ; de ; Funktioniert nicht 
     2 ; en ; ... 
+2

我會在原始表格中保留英文/中性語言版本(並且標記爲非空),所以如果還沒有被翻譯,總有一個後備。 – 2011-06-14 14:04:44

+0

我可以看到這種方法的好處,但隨着數據被聚合到一個OLAP數據庫中,您將失去總體頂級(所有語言)聚合,因爲故障會有不同的ID – 2011-06-14 15:10:29

+2

@Phil Murray - 我認爲其意圖是'tblFault_Labels'中的'ID'是'tblFault-> ID'的FK - 每個故障都有一個唯一的'ID',與用於選擇它的語言無關。 – 2011-06-14 16:50:40

0

更多的東西一樣所以很有可能:

tblFault 
ID ; Lang ; Description 
1 ; EN ; Not Functional 
... 
1

這絕對是一種方法。

我以前在這種情況下使用的另一種方法是創建一個「LanguageId」列。

通常我會是這樣的:

StringId, LanguageId, Description 
1   0    Hello 
1   1    Hola 
1   2    Bon Jour 

這讓我寫一個查詢,如果字符串35(例如)沒有我要找的語言,我還可以提供英語。有了這樣的想法,有什麼比沒有好。

這種方法的缺點是複合主鍵和一些連接邏輯。