存储内容翻译的有效方法？答案

【问题标题】：Efficient way to store content translations?存储内容翻译的有效方法？
【发布时间】：2009-11-04 10:22:52
【问题描述】：

假设您有一些非常大的 (100k+) 对象可用，并且可以以 20 多种语言提供这些数据（例如名称）。在 SQL 数据库中存储/处理这些数据的有效方法是什么。

这样做的明显方法看起来像这样 - 但是，还有其他更有意义的方法吗？我有点担心性能。

  CREATE TABLE "object" (
      "id" serial NOT NULL PRIMARY KEY
  );                                  
  CREATE TABLE "object_name" (
      "object_id" integer NOT NULL REFERENCES "object" ("id")
      "lang" varchar(5) NOT NULL,
      "name" varchar(50) NOT NULL 
  );

就用法而言，使用只会选择一种语言，这将导致object_name 表上的潜在大连接。

无论是否过早优化，我都对其他方法感兴趣，如果只是让自己安心，那么显而易见的解决方案并不是一个非常愚蠢的解决方案。

要阐明实际模型要复杂得多。这只是目前确定的模式。

【问题讨论】：

标签： sql database performance internationalization translation

【解决方案1】：

如果您在 (object_id, lang) 上有一个组合键，则不应该有任何连接，只需 O(1) 查找，对吗？（试试EXPLAIN SELECT 确定）

【讨论】：

【解决方案2】：

在我自己的项目中，我不会在数据库级别进行翻译。我让用户（或操作系统）给我一个语言代码，然后我将所有文本一次性加载到哈希中。然后数据库向我发送该哈希的 ID，我会在将文本显示在某处时翻译它们。

请注意，我的 ID 也是字符串。这样，您就可以看到您正在使用的文本（比较“USER”和“136”——谁知道“136”在 UI 中可能意味着什么？）。

[编辑] 如果您无法在 UI 级别进行翻译，那么您的数据库设计就是您可以达到的最佳目标。它尽可能小，易于索引并且连接不需要太多。

如果您想更进一步，并且可以在应用程序级别生成 SQL 查询，您可以考虑创建视图（每种语言一个），然后在连接中使用视图，这将为您提供一种方法避免两列连接。但我怀疑这种复杂的方法是否会产生积极的投资回报率。

【讨论】：

这适用于字符串数量有限的 UI，但他想要有 100k+ 个对象/字符串的东西，我不会将它们保存在内存中......
我认为他的意思是一个翻译表，将 msg_id 映射到翻译。这不是我可以使用 gettext 的东西。
@Wim：我仍然觉得我会避免在数据库级别这样做。如果有这么多对象，我会在 UI 级别使用缓存。
这取决于使用模式，如果没有太多重用，那么缓存将无济于事。但无论如何都值得调查。

【解决方案3】：

您是否考虑过使用多个表，每种语言一个表？

在编码复杂性方面会花费更多，但您将只加载/访问每种语言的一个表，其中元数据会更小，因此更省时（可能也是空间方面的，因为你不会'每行都有一个“lang”变量）

另外，如果你真的想要一个表来统治他们，你可以创建一个视图并加入他们:)

【讨论】：

为什么不在同一个表中添加一些字段呢？如果我还是要对语言进行“硬编码”？

【解决方案4】：

除了 Wim 写的之外，您的情况下的表 OBJECT 是没用的。不需要这样的表，因为它不存储任何不包含在表 OBJECT_NAME 中的单个信息。

【讨论】：