时间戳

首页 > 解决方案 > 具有相似可翻译字段的多语言数据库设计

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

问题描述

我没有为我正在从事的新项目设计数据库模式。

因此，挑战如下：

我看到有两个选项：

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 个字符长的文本使用相同的列类型有什么缺点吗？

标签： mysqldatabasedatabase-designlocalizationinternationalization

解决方案

这样做并避免向用户显示垃圾的好方法：

在您的 Items 表中放置一个实际的描述字段。例如，美国（我们在度量衡方面落后）可能是：

Bread, brown, 1 pound loaf

然后构建一个包含三列的翻译表：lang, original, translate`。

例如：

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）中的本地化是值得的。

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

假设您的翻译表中有一千万个项目。这将是平均每个项目 200 字节。使用索引，假设每个项目 400 字节。那是 4 GB 的表。在高质量的云机器中，这将花费大约 0.11 到 0.14 美元/月。使用 ID 会比它的一半少一点。说 1.5 GB。因此，差异约为每月 0.06 美元。此外，云机器具有最小的存储大小。

查找：如果您正确索引表，文本匹配不会比 id 匹配慢很多。而且，它不会大量发生，而是在人们查找信息时发生。

推荐阅读