Question

对于那些经常使用多语言网站和电子商店的有经验的人来说，这更是一个问题。这不是数据库结构问题或类似的问题。这是关于如何存储多语言网站的问题：不是如何存储翻译。多语言网站不仅可以翻译成多种语言，还可以具有特定语言的内容。例如，该网站的英文版本可以具有与俄语或任何其他语言的相同网站完全不同的结构。对于这种情况，我已经考虑了两种存储模式：

// NUMBER ONE

table contents // to store some HYPOTHETICAL content
    id         // content id

table contents_loc // to translate the content
    content, // ID of content to translate 
    lang,    // language to translate to
    value,   // translated content
    online   // availability flag, VERY IMPORTANT

ADVANTAGES:
- Content can be stored in multiple languages. This schema is pretty common, except maybe for the "online" flag in the "_loc" tables. About that below.
- Every content can not only be translated into multiple languages, but also you could mark online=false for a single language and disable the content from appearing in that language. Alternatively, that record could be removed from "_loc" table to achieve the same functionality as online=false, but this time it would be permanent and couldn't be easily undone. For instance we could create some sort of a menu, but we don't want one or more items to appear in english - so we use online=false on those "translations".

DISADVANTAGES:
- Quickly gets pretty ugly with more complex table relations.
- More difficult queries.



// NUMBER 2

table contents // to store some HYPOTHETICAL content
    id,        // content id
    online     // content availability (not the same as in first example)
    lang,      // language of the content
    value,     // translated content

ADVANTAGES:
1. Less painful to implement
2. Shorter queries

DISADVANTAGES:
2. Every multilingual record would now have 3 different IDs. It would be bad for eg. products in an e-shop, since the first version would allow us to store different languages under the same ID and this one would require 3 separate records to represent the same product.

第一个存储选项似乎是一个很好的解决方案，因为你可以轻松地使用它而不是第二个，但你不能轻易地使用它。唯一的问题是......第一个结构看起来有点像矫枉过正（产品存储除外）

所以我的问题是：

实施第一个存储选项是否合乎逻辑？根据您的经验，是否有人需要这样的解决方案？

Answer 1

我们问自己的问题始终是：

多种语言的内容是否相同，是否需要关系？

可转换模型

如果答案是肯定的，那么你需要一个可翻译的模型。所以一个模型具有相同记录的多个版本。因此，您需要为每条记录添加语言标记。

PROS：它为您提供了一个结构，您可以在其中查看哪些内容尚未翻译。

每种语言的单独记录 但很多时候我们看到一个不同的解决方案是更好的解决方案：完全分开两种语言。我们主要在CMS解决方案中看到这一点故事不仅翻译而且不同。例如，在国家1中，他们有不同的菜单结构，其他新闻，其他产品和其他页面。

PROS：完全灵活，没有其他语言的意外记录。

示例我们认为这就像写一本杂志：你可以写一本，然后翻译成另一种语言。是的，这是可能的，但在现实世界中，我们越来越多地看到内容在结构上是不同的。人们不喜欢惊讶所以你需要很多步骤来确保内容在错误的语言中不可见，页面不会被创建为重复等。

分享逻辑 所以我们所做的就是大部分时间：分享视图，使按钮，输入等可翻译但保持内容分离。这样每个管理员都可以在他的区域工作。如果我们需要确认某些记录可用于所有语言，我们总是可以通过在它们之间创建一个链接（很好的关系）来欺骗它，但它不是我们大多数时候使用的标准。

真正可翻译的记录，如产品 因为我们可以灵活地创建模型等，所以我们可以根据需求决定如何使用它们。我不会试图寻找适合所有人的通用解决方案，因为没有。您需要基于数据的解决方案。

Answer 2

假设你需要一个可翻译模型，正如Luc所描述的那样，我建议为某个值的列列出一些特殊字符分隔的键值对格式。内容表。例如：

@ en =英语术语@ de =德语术语

您可以使用UDF（T-SQL中的用户定义函数）根据指定的语言设置/获取适当的术语。

选择：

选择id，dbo.GetContentInLang（value，@ lang）来自内容

更新：

更新内容 set value = dbo.SetContentInLang（value，@ lang，new_content）其中id = @id

UDF：

一个。确实有性能损失，但这也是内容和content_loc表之间必须进行的连接的情况

和

湾在某种程度上难以实现，但几乎可以在整个数据库中重用。

您也可以在应用程序/ UI层执行上述操作。

需要有关多语言数据存储的建议

2 个答案: