mysql - 具有相似可翻译字段的多语言数据库设计

Question

我不在为我正在进行的新项目设计数据库模式。

那么，挑战如下:

• 有一个表Items
• 每个Item都有一个可翻译description_60、description_180文本，(后缀数字代表类型存储的描述，例如 60 表示 60 个字符长)和一些与每个描述相关的字段，例如 apiSourceNameetc.

我看到了两个选项:

1

descriptions_translations

  Id
description_60
description_180
description_300
apiSourceName_60
apiSourceName_180
....
...

这看起来不太好，因为我们可能会得到很多 NULL 字段 和

2

descriptions_60_translations
  Id
description_60
apiSourceName
languageId
...
...

3 其他？

我完全接受其他建议!

另外，另一个挑战是我想在主 Item 表中存储 description_60 文本。如果不复制数据，这可能吗？

更新 根据答案更倾向于这个:

descriptions_translations
=========================
  id
itemId
description_type =>60, 120, 180 etc
`description` => 'This video is ...'
apiSourceName => youtube, dailymotion etc
languageId => en, es etc
...
...

对 60 个字符和 1000 个字符长的文本使用相同的列类型有什么缺点吗？

Answer 1

执行此操作并避免向用户显示垃圾的好方法:

在您的项目表中放置一个实际的描述字段。例如，美国(我们在度量衡方面落后)可能是:

Bread, brown, 1 pound loaf

然后构建一个包含三列的翻译表:lang、original、translated`。

例如:

lang   original                     translated
 es    Bread, brown, 1 pound loaf   Hogaza de pan integral, 450g
 fr    Bread, brown, 1 pound loaf   Miche de pain brun, 450g
 de    Bread, brown, 1 pound loaf   Laib Schwarzbrot, 450g

然后执行这样的查询以获取翻译:

SELECT COALESCE(t.translated, i.name) as name
  FROM Items
  LEFT JOIN Translation t ON t.lang = 'se' AND i.name = t.translated

这样，您的瑞典客户将获得原始商品名称(直到您提供瑞典语翻译)，而您的墨西哥客户将获得适当的翻译。诀窍是 COALESCE ... LEFT JOIN 查询模式。

您可能希望根据名称 id 值而不是名称本身来匹配翻译。但是，对于在 WordPress 等常见系统中进行本地化的值(value)，就像我建议的那样匹配名称的文本。

编辑关于使用文本而不是 id 进行匹配的效率。

假设您的翻译表中有一千万个项目。平均而言，每个项目 200 字节。对于索引，假设每个项目 400 个字节。该表有 4 GB。在一台高质量的云机器上，这将花费大约每月 0.11 到 0.14 美元。使用 ID 将略低于一半。比如说 1.5 GB。因此，差额约为每月 0.06 美元。此外，云计算机具有最小存储大小。

查找:如果您正确地为表编制索引，文本匹配不会比 ID 匹配慢很多。而且，它不会批量发生，而是在人们查找信息时发生。