设计本地化数据库模式

Question

可能重复:
多语言数据库的模式

我正在开发一个我计划以多种语言提供的Web应用程序.在设计数据库时,我会在两种不同的方式之间来回传递,以便在数据库中存储本地化描述和诸如此类的东西.

第一个选项是众所周知的table_name,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类型内容(网页上的静态文本等)

我喜欢第一个选项,因为它尝试过并且是真的,但第二个选项似乎还有很多其他优点:

1. 我的所有文本/本地化内容都在一个地方(使翻译更容易).
2. 服务层实际上并不需要关心语言环境.
3. 通过不必加入一堆ML类型表来简化查询.

由于我以前从未见过这样的设计,我认为我必须遗漏一些东西.有没有好的理由不以这种方式设计呢？或者也许有一个我没有想过的更好的选择？

Answer 1

我首先要说的是，我以前没有处理过本地化问题，所以这只是我的意见，而不是基于经验。

我喜欢你的第二个选择。就数据库而言……它的数据以及访问/操作数据的方法。在这种情况下，所有数据都在那里，您将主要阅读它并有一个很好的方法来获取它。您可以在这两种情况下回答相同的问题。我自己更喜欢第二种选择，因为它减少了到处都是疯狂的桌子。您为了翻译的特定目的而保留一张桌子。您可以重用它（无需为以后升级而创建更多表）并且它可以保持完整性。如果某个地方有意义的话，您甚至可以重复使用名称。就像您将“Mantequilla”作为类别并在其他地方作为收藏夹一样。

我喜欢尽可能将相关数据放在一张表中，而不是在多个位置放置与“翻译”相关的数据。

唯一可能失败的地方是，如果您不仅仅有需要翻译的内容的名称和说明。也许您有某个项目的名称、描述、代码、魔词、愚蠢的昵称等。虽然您可以通过在相关表中添加更多 NameToken 并重用 Name 来解决此问题，但这有点麻烦。

只要确保模型满足每个人的需求并且它应该可以正常工作。如果稍后需要针对特定​​表，您始终可以添加特殊的转换表。这与创建大量表没有什么不同，尽管混合解决方案可能会令人困惑。最好找到一种方法并努力坚持下去。