多语言数据库的架构

Question

多语言数据库的架构我正在开发一个多语言软件。就应用程序代码而言，本地化不是问题。我们可以使用特定于语言的资源，并拥有各种工具，它们可以很好地工作。但是，定义多语言数据库模式的最佳方法是什么？假设我们有很多表(100或更多)，每个表可以有多个可以本地化的列(大多数nvarchar列应该是可本地化的)。例如，其中一个表可能保存产品信息：CREATE TABLE T_PRODUCT (   NAME        NVARCHAR(50),   DESCRIPTION NTEXT,   PRICE       NUMBER(18, 2))我可以想到三种方法来支持名称和描述列中的多语言文本：每种语言的单独列当我们向系统添加一种新语言时，我们必须创建额外的列来存储翻译的文本，如下所示：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))每种语言都有列的翻译表只存储翻译表的外键，而不是存储翻译文本。“翻译”表包含每种语言的一列。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)每种语言都有行的翻译表只存储翻译表的外键，而不是存储翻译文本。“翻译”表只包含一个键，另一个单独的表包含每个翻译成一种语言的行。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

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

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