設計一個本地化的數據庫架構

可能重複：
Schema for a multilanguage database 設計一個本地化的數據庫架構

我的工作，我打算在多國語言，提供一種Web應用程序。在設計數據庫時，我會在兩種不同的方式之間來回存儲本地化描述以及數據庫中的內容。

第一個選項是衆所周知的表名，table_name_ml類型選項：

TABLE Category (
    ID int, 
    ParentID int, 
    Name varchar(50), 
    Description varchar(255) 
) 

TABLE Category_ML (
    ID int, 
    CategoryID int, 
    LocaleID int, 
    Name varchar(50), 
    Description varchar(255) 
)

第二個選擇是不存儲在所有基本表的文字，而是存儲可以使用令牌到別處查找實際的本地化的文本，像這樣：

TABLE Category (
    ID int, 
    ParentID int, 
    NameToken varchar(50), 
    DescriptionToken varchar(50), 
) 

// Tables in a separate content management type system 
TABLE Content (
    ID int, 
    Token varchar(50) 
) 

TABLE Translation (
    ID int 
    ContentID int, 
    LocaleID int, 
    Value text 
)

這裏的想法是，內容和翻譯表將保持在數據庫中的許多不同的實體本地化的文本。服務層只會使用令牌返回基礎對象，並且視圖層會使用內容/轉換表查找實際的文本值 - 這會大量緩存。內容/翻譯表也可用於存儲其他CMS類型的內容（網頁上的靜態文本等）

我喜歡第一個選項，因爲它的嘗試和真實，但第二個選項似乎有這麼多其他選項優點：

我所有的文本/本地化內容都在一個地方（使翻譯更容易）。
服務層並不需要關心語言環境。
通過不必加入一堆ML類型表來簡化查詢。

因爲我以前從未見過這樣的設計，所以我認爲我必須缺少一些東西。有沒有這樣設計的好理由？或者，也許有更好的選擇，我沒有想到？

來源

2010-01-12 Eric Petroelje

？難道你只是用你的代幣直接在翻譯表中查找翻譯？ – 2011-01-20 15:50:46

沒有，我認爲它，如果令牌只持有像信息。。爲什麼表類別無論如何都需要token-properties？ – 2011-01-20 16:03:46

@paskster - 內容表用於避免在翻譯表中重複標記列。對於給定的令牌會有很多翻譯。如果需要，它還允許您在類別表格和內容表格之間擁有RI。 – 2011-01-20 16:15:38

我會先說我沒有處理過本地化的問題，所以這只是我的看法，而不是基於經驗。

我喜歡你的第二個選項。就數據庫而言，其數據和訪問/操作數據的方式一樣。在這種情況下，所有的數據都在那裏，你將主要閱讀它，並有一個很好的方法來獲得它。您可以在兩種情況下回答相同的問題。我更喜歡第二種選擇，因爲它可以減少各處的瘋狂表格。爲了翻譯的具體目的，你要保留一張表格。您可以重複使用它（不會爲稍後的升級創建更多表），並且它會保持完整性。如果某個地方有意義，你甚至可以重用名稱。就好像你在其他地方有'Mantequilla'作爲一個類別和一個收藏。

我喜歡在可能的情況下將相關數據放在一張表中，並且沒有與多處翻譯相關的數據。

這可能會失敗的唯一途徑是如果您不僅僅需要翻譯名稱和描述。也許你有一個項目的名稱，說明，代碼，魔術字，愚蠢的綽號等。雖然你可以通過在該相關表中添加更多NameTokens並重新使用Name來解決這個問題，但這有些破綻。

只要確保模型滿足您的需求，每個人都應該很好地工作。如果以後需要特定的表格，您可以隨時輸入特殊翻譯表格。這與創建大量表格不同，儘管混合解決方案可能會造成混淆。最好找到一種方法並嘗試堅持下去。

來源

2010-01-12 21:08:40

不僅僅是名稱和描述不應該是一個問題。令牌字段只是一個自由形式的文本片段。例如，ID爲1的類別的「NameToken」可能是'DB.Category.1.Name'。如果我在該表上有一個名爲「MagicWord」的字段，那麼它的標記可能是'DB.Category.1.MagicWord'。所以，一般來說，令牌將被命名爲'DB'。。。 '。希望更有意義。 – 2010-01-13 13:19:43

好吧，那麼看起來你有所有我能想到的計劃出來的情況:)似乎對我來說是一個很好的模型。 – 2010-01-13 17:06:52

-1

有一個額外的選擇，我想我會賭這個！

分離數據庫完全！

原因（PROS）：

Pyhsically分隔的局部數據庫
腳手架（生成的表示層）
易奧姆

缺點：

你要解決問題唯一ID（複製）
你需要爲什麼你有一個表的內容同步模式和非定位數據

來源

2011-05-18 15:57:14

你的「專業人員」是事實，而不是優點。「利弊」對小「專業人士」來說相當沉重。 – SandRock 2012-04-05 20:14:15

Serhat沒有提到殺戮專業版：對於大型分貝，它針對重型語言信息搜索進行了優化 - 它已經是語言分離的。但這僅適用於大型dbs。 – aiho 2013-01-09 09:15:52

設計一個本地化的數據庫架構

回答

相關問題