表格的语言翻译

我知道大多数人使用下面的方法并为需要翻译的特定表创建一个翻译表，但这可能会导致大量表的负载。

CREATE TABLE Product
(
     Product_id
    ,ProductTrans_id -- FK
)

CREATE TABLE ProductTranslation
(
     ProductTrans_id
    ,Product_id
    ,Name
    ,Descr
    ,lang_code
)

下面的方法可行吗？假设您有很多表，其中超过 1 列需要翻译。您可以执行以下操作并将所有翻译保留在 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)
        )   

所以使用第二种方法你会得到像这样的文本

select 
     product.name 
    ,translation_entry.translated_text
from product
inner join  translation_entry on product.product_id = translation_entry.table_row_id 
and translation_entry.table_name = 'Product' and translation_entry.table_column_name = 'Name'
and language_id = 3

我不确定您为什么担心表的数量：表较少并不意味着您的数据库更小、更高效或设计更好。特别是如果减少表的数量会增加查询的复杂性，我会非常小心地这样做。

无论如何，我会为每个“基”表选择一个转换表。主要原因是您的第二个解决方案不灵活：如果主键不是单个整数，那么实现和使用将变得极其困难。查询翻译也更加复杂，并且根据表和数据的大小，可能很难对其进行有效索引。

目前尚不清楚为什么你有一个TranslationID on the Products桌子;通常这种关系是相反的：

create table dbo.Products (
    ProductCode char(10) not null primary key,
    ProductName nvarchar(50) not null,
    ProductDescription nvarchar(100) not null,
    -- other columns
)

create table dbo.ProductsTranslations (
    ProductCode char(10) not null,
    LanguageCode char(2) not null,
    ProductName nvarchar(50) not null,
    ProductDescription nvarchar(100) not null,
    -- other translations
    constraint FK1 foreign key (ProductCode)
        references dbo.Products (ProductCode),
    constraint FK2 foreign key (LanguageCode)
        references dbo.Languages (LanguageCode),
    constraint PK primary key (ProductCode, LanguageCode)
)

根据您的工具集和部署过程，您可能希望直接从基础表生成转换表，作为数据库构建的一部分。您还可以使用视图来提供方便的、“完全翻译”的基表版本。

一个有趣的问题是，中的列使用什么语言Products以及是否可以在不需要翻译的情况下直接使用。我的建议是所有生产代码都应该传递语言参数并从ProductsTranslations仅表，即使是英语（或任何您的内部公司语言）。这样，您可以确保在同一个表中找到所有“官方”名称，并且基表上的列是为了数据模型的清晰性和完整性以及开发人员的便利性和（可能）临时内部使用而存在的报告等。