下面的方法是否可行?假设您有多个表，其中有超过1个列需要转换。所以对于产品来说，你可能同时需要翻译产品名称和产品描述。你能做到以下几点吗?

CREATE TABLE translation_entry (
      translation_id        int,
      language_id           int,
      table_name            nvarchar(200),
      table_column_name     nvarchar(200),
      table_row_id          bigint,
      translated_text       ntext
    )

    CREATE TABLE translation_language (
      id int,
      language_code CHAR(2)
    )   

我通常会选择这种方法(不是实际的sql)，这对应于您的最后一个选项。

table Product
productid INT PK, price DECIMAL, translationid INT FK

table Translation
translationid INT PK

table TranslationItem
translationitemid INT PK, translationid INT FK, text VARCHAR, languagecode CHAR(2)

view ProductView
select * from Product
inner join Translation
inner join TranslationItem
where languagecode='en'

因为将所有可翻译文本放在一个地方可以使维护工作更加容易。有时翻译外包给翻译机构，这样你就可以给他们发送一个大的导出文件，然后很容易地导入回来。

看看这个例子:

PRODUCTS (
    id   
    price
    created_at
)

LANGUAGES (
    id   
    title
)

TRANSLATIONS (
    id           (// id of translation, UNIQUE)
    language_id  (// id of desired language)
    table_name   (// any table, in this case PRODUCTS)
    item_id      (// id of item in PRODUCTS)
    field_name   (// fields to be translated)
    translation  (// translation text goes here)
)

我认为没有必要解释，结构本身就说明了这一点。

您需要记住，在创建多语言数据库时，您正在从产品表中删除名称或描述等字段，并将其移动到已翻译的资源中。

翻译后的资源可以是另一个表，就像我的例子一样，它被设计成与SQL视图一起工作，以简化查询和友好地开发底层应用程序

我分离了LabelTranslations，因为这是一个网页上字段标签的全局翻译表。你可以随意称呼它，它们是无状态的，不依赖于特定的产品或类别。

ProductTranslations的CategoryTranslations是有状态的，这意味着“name”的描述符将是实际的产品名称。

与简单的SQL视图相比，使用物化视图可以获得更好的性能(使用存储空间的成本和更多的精力用于底层应用程序开发来刷新它们)，或者如果你想要使用更重的SQL视图。

在Postgres中创建类别物化视图:

CREATE MATERIALIZED VIEW VCategories AS (
    SELECT cat.id, lng.iso_639_1_code, ct.descriptor, ct.value
    FROM Categories cat
    JOIN CategoryTranslations ct ON ct.category_id = cat.id
    JOIN Languages lng ON lng.id = ct.language_id
);

查询ID为120的类别的所有翻译

SELECT * FROM VCategories WHERE id = 120 AND iso_639_1_code = 'en'

我觉得在使用应用程序的代码时很方便，您可以编写非常简单的代码来查询翻译和搜索记录

第三种选择是最好的，原因如下:

Doesn't require altering the database schema for new languages (and thus limiting code changes) Doesn't require a lot of space for unimplemented languages or translations of a a particular item Provides the most flexibility You don't end up with sparse tables You don't have to worry about null keys and checking that you're displaying an existing translation instead of some null entry. If you change or expand your database to encompass other translatable items/things/etc you can use the same tables and system - this is very uncoupled from the rest of the data.

亚当

“哪一个是最好的”是基于项目的情况。第一种方法易于选择和维护，并且在选择实体时不需要连接表，性能最好。如果你确认你的项目只支持2或3种语言，并且不会增加，你可以使用它。

第二个是可以的，但是很难理解和维护。而且表现比第一个还差。

最后一种方法在可伸缩性方面很好，但在性能方面很差。T_TRANSLATION_ENTRY表将变得越来越大，当你想从一些表中检索一个实体列表时，这是很糟糕的。