多语言应用的数据库设计问题答案

【问题标题】：Database design problem for multiple language application多语言应用的数据库设计问题
【发布时间】：2011-07-28 12:47:34
【问题描述】：

我们正在开发一个旅行门户，对于一个旅行门户，它的内容和细节是核心。我们计划在多个区域设置它，因此这意味着我们需要处理每个区域的动态数据。

目前我们有以下表格

Destination
Transport
Places of Interests
user comments etc.

每个表都包含很多字段

Name
ShortDescription
LongDescription

以及许多其他可能包含大量数据的字段，我们需要以特定于语言环境的方式处理数据。

我不确定我们可以如何最好地设计一个应用程序来处理这种情况，我想到的一件事就是在每个表中为每个区域设置额外的列，但这意味着对于新的区域设置需要从数据库中进行更改到代码级别，这根本不好。

由于每个表都包含很多列，这些列可以包含符合国际化条件的数据，所以我的问题是处理这种情况的最佳方法是什么

编辑1 在做了一些分析和一些观察之后，我想到的一种方法如下..

我打算为每个表创建一个翻译表喜欢目的地我有以下设计

    table languages
    -- uuid (varchar)
    -- language_id(varchar)
    -- name (varchar)  

    table Destination
    --uuid (varchar)
     other fields which are not part of internationalization.

table Destination_translation
-- id (int)
-- destination_id (int)
-- language_id (int)
-- name (text)
-- description(text)

欢迎对上述方法提出任何有价值的建议......

【问题讨论】：

标签： database database-design internationalization application-design

【解决方案1】：

在以前对应用程序进行国际化时，我们有一个基于区域设置的值表。所以，我们做了这样的事情：

创建一个名为 local_strings 的表，由 string_code、locale_code、值组成。这包含各种值的翻译。因此，如果您已翻译成三种语言，则每个 string_code 将有三个具有不同 locale_code 的条目..

然后，每个主表（在您的情况下为目的地、运输等）都引用了 local_strings 表中的 string_code。

最后，在从数据库中查询值时，只要确保始终加入 local_strings 表并始终使用用户当前的语言环境。或者，您可以将这些值缓存在内存中，这样您就不必总是加入该表。但是，根据我的经验，表格永远不会变得那么大，因此加入它并没有太多开销。

【讨论】：

【解决方案2】：

有几种方法可以解决这个问题：

通过区域设置列扩展表，并在每个查询中包含区域设置。您甚至可以修改索引以包含 locale 列。
为本地化字符串创建单独的表

我肯定会支持选项 1，因为它使表格看起来仍然像真实的东西，并且仍然可以通过直接查看数据来读取它们。它还可以防止您进行子选择或连接，这有助于提高性能。选项 2 的优点只是对管理界面的程序员来说更容易（如果你有的话）。

【讨论】：