设计一个本地化的数据库架构

可能重复：
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

设计一个本地化的数据库架构

回答

相关问题