多语言数据库的架构 [英] Schema for a multilanguage database

问题描述

我正在开发一种多语言软件。就应用代码而言，本地化不是问题。我们可以使用语言特定的资源，并且可以使用各种各样的工具。

但是，定义多语言数据库模式最好的方法是什么？假设我们有很多表（100个或更多），并且每个表可以有多个可以被本地化的列（大多数nvarchar列应该是可本地化的）。例如其中一个表可能会保存产品信息：

  CREATE TABLE T_PRODUCT（
 NAME NVARCHAR（50），
描述NTEXT，
 PRICE NUMBER（18，2）
）
  

我可以想到在NAME和DESCRIPTION列中支持多语言文本的三种方法：

1. 分开每个语言的列

   
   
   

   当我们向系统添加新语言时，我们必须创建其他列来存储翻译的文本，如下所示：

     CREATE TABLE T_PRODUCT（
    NAME_EN NVARCHAR（50），
    NAME_DE NVARCHAR（50），
    NAME_SP NVARCHAR（50），
    DESCRIPTION_EN NTEXT，
    DESCRIPTION_DE NTEXT，
    DESCRIPTION_SP NTEXT，
    PRICE NUMBER（18,2）
   ）
     




2. 具有每种语言列的翻译表

   
   
   

   存储翻译文本时，仅存储翻译表的外键。翻译表包含每个语言的列。

     CREATE TABLE T_PRODUCT（
    NAME_FK int，
    DESCRIPTION_FK int，
    PRICE NUMBER（18，2）
   ）
    
    CREATE TABLE T_TRANSLATION（
    TRANSLATION_ID，
    TEXT_EN NTEXT， 
    TEXT_DE NTEXT，
    TEXT_SP NTEXT 
   ）
     




3. 具有每种语言行的翻译表

   
   
   

   代替存储翻译文本，只存储翻译表的外键。翻译表只包含一个键，单独的表包含每个翻译成语言的行。

     CREATE TABLE T_PRODUCT（
    NAME_FK int，
    DESCRIPTION_FK int，
    PRICE NUMBER（18，2）
   ）
    
    CREATE TABLE T_TRANSLATION（
    TRANSLATION_ID 
   ）
    
    CREATE TABLE T_TRANSLATION_ENTRY（
    TRANSLATION_FK，
    LANGUAGE_FK，
    TRANSLATED_TEXT NTEXT 
   ）
    
    CREATE TABLE T_TRANSLATION_LANGUAGE（
    LANGUAGE_ID，
    LANGUAGE_CODE CHAR（2）
   ）
     

每个解决方案都有优缺点，我想知道您对这些方法的体验是什么，你推荐什么以及如何去

解决方案

您有什么想要为每个可翻译表格提供相关的翻译表？

CREATE TABLE T_PRODUCT（pr_id int，PRICE NUMBER（18，2））

CREATE TABLE T_PRODUCT_tr（pr_id INT FK，languagecode varchar，pr_name文本，pr_descr文本）

这样，如果您有多个可翻译列，一个单一的联接来获得它+因为你不是自动生成一个翻译，它可能会更容易导入项目及其相关的翻译。

这样做的消极方面是，如果您有一个复杂的语言后备机制，您可能需要为每个翻译表实现 - 如果您依赖某些存储过程来执行此操作。如果你从应用程序这样做，这可能不会是一个问题。

让我知道你的想法 - 我也要作出一个决定，为我们的下一个应用。
到目前为止，我们已经使用了你的第三种类型。

I'm developing a multilanguage software. As far as the application code goes, localizability is not an issue. We can use language specific resources and have all kinds of tools that work well with them.

But what is the best approach in defining a multilanguage database schema? Let's say we have a lot of tables (100 or more), and each table can have multiple columns that can be localized (most of nvarchar columns should be localizable). For instance one of the tables might hold product information:

CREATE TABLE T_PRODUCT (
  NAME        NVARCHAR(50),
  DESCRIPTION NTEXT,
  PRICE       NUMBER(18, 2)
)

I can think of three approaches to support multilingual text in NAME and DESCRIPTION columns:

1. Separate column for each language

   When we add a new language to the system, we must create additional columns to store the translated text, like this:

   CREATE TABLE T_PRODUCT (
     NAME_EN        NVARCHAR(50),
     NAME_DE        NVARCHAR(50),
     NAME_SP        NVARCHAR(50),
     DESCRIPTION_EN NTEXT,
     DESCRIPTION_DE NTEXT,
     DESCRIPTION_SP NTEXT,
     PRICE          NUMBER(18,2)
   )
   

2. Translation table with columns for each language

   Instead of storing translated text, only a foreign key to the translations table is stored. The translations table contains a column for each language.

   CREATE TABLE T_PRODUCT (
     NAME_FK        int,
     DESCRIPTION_FK int,
     PRICE          NUMBER(18, 2)
   )
   
   CREATE TABLE T_TRANSLATION (
     TRANSLATION_ID,
     TEXT_EN NTEXT,
     TEXT_DE NTEXT,
     TEXT_SP NTEXT
   )
   

3. Translation tables with rows for each language

   Instead of storing translated text, only a foreign key to the translations table is stored. The translations table contains only a key, and a separate table contains a row for each translation to a language.

   CREATE TABLE T_PRODUCT (
     NAME_FK        int,
     DESCRIPTION_FK int,
     PRICE          NUMBER(18, 2)
   )
   
   CREATE TABLE T_TRANSLATION (
     TRANSLATION_ID
   )
   
   CREATE TABLE T_TRANSLATION_ENTRY (
     TRANSLATION_FK,
     LANGUAGE_FK,
     TRANSLATED_TEXT NTEXT
   )
   
   CREATE TABLE T_TRANSLATION_LANGUAGE (
     LANGUAGE_ID,
     LANGUAGE_CODE CHAR(2)
   )
   

There are pros and cons to each solution, and I would like to know what are your experiences with these approaches, what do you recommend and how would you go about designing a multilanguage database schema.

解决方案

What do you think about having a related translation table for each translatable table?

CREATE TABLE T_PRODUCT (pr_id int, PRICE NUMBER(18, 2))

CREATE TABLE T_PRODUCT_tr (pr_id INT FK, languagecode varchar, pr_name text, pr_descr text)

This way if you have multiple translatable column it would only require a single join to get it + since you are not autogenerating a translationid it may be easier to import items together with their related translations.

The negative side of this is that if you have a complex language fallback mechanism you may need to implement that for each translation table - if you are relying on some stored procedure to do that. If you do that from the app this will probably not be a problem.

Let me know what you think - I am also about to make a decision on this for our next application. So far we have used your 3rd type.

这篇关于多语言数据库的架构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！