多语言数据库的架构

Question

多语言数据库的架构

我正在开发一个多语言软件。就应用程序代码而言，本地化不是问题。我们可以使用特定于语言的资源，并拥有各种工具，它们可以很好地工作。

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

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

我可以想到三种方法来支持名称和描述列中的多语言文本：

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))

每个解决方案都有优缺点，我想知道您对这些方法的经验，您推荐的是什么，以及如何设计一个多语言的数据库模式。

Answer 1

第三种选择是最好的，原因如下：不需要更改新语言的数据库架构(从而限制代码更改)不需要为未实现的语言或特定项的翻译占用大量空间提供最大的灵活性你不会有稀疏的桌子您不必担心空键，也不必检查是否正在显示一个现有的转换，而不是一些空条目。如果更改或扩展数据库以包含其他可翻译的项/事物/等，则可以使用相同的表和系统-这与其他数据非常不耦合。