设计一个本地化的数据库模式
可能重复：
多语言数据库的架构
我正在研究一个我打算以多种语言提供的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类型的内容（网页上的静态文本等）
我喜欢第一种选择，因为它的尝试和真实，但第二种选择似乎有其他许多优点：
由于我从来没有见过这样的设计，所以我认为我必须错过一些东西。 有没有这样设计的好理由？ 或者，也许有更好的选择，我没有想到？
我首先会说我以前没有处理过本地化，所以这只是我的看法，而不是基于经验。
我喜欢你的第二个选项。 就数据库而言，其数据和访问/操作数据的方式一样。 在这种情况下，所有的数据都在那里，你将主要阅读它，并有一个很好的方法来获得它。 您可以在两种情况下回答相同的问题。 我更喜欢第二种选择，因为它可以减少各处的疯狂表格。 为了翻译的具体目的，你要保留一张表格。 您可以重复使用它（不会为稍后的升级创建更多表），并且它会保持完整性。 如果某个地方有意义，你甚至可以重用名称。 就好像你在其他地方有'Mantequilla'作为一个类别和一个收藏。
我喜欢在可能的情况下将相关数据放在一张表中，而不是在多个地方有与“翻译”有关的数据。
唯一可能会失败的地方是如果你不仅仅需要翻译名称和描述。 也许你有一个项目的名称，说明，代码，魔术字，愚蠢的绰号等。 虽然你可以通过在该相关表中添加更多NameTokens并重新使用Name来解决这个问题，但这有些破绽。
只要确保模型满足你的需求，它应该可以正常工作。 如果以后需要特定的表格，您可以随时输入特殊翻译表格。 这与创建大量表格不同，尽管混合解决方案可能会造成混淆。 最好找到一种方法并尝试坚持下去。
有一个额外的选择，我想我会在这个赌注！
理由（PROS）：
缺点：