当前位置: 首页 > 知识库问答 >
问题:

用于国际和多语言目的的数据库建模

诸葛柏
2023-03-14

我需要为一个多语言的web应用程序创建一个大型数据库模型

每次我思考如何做的时候,我都有一个疑问,那就是如何解决一个字段的多次翻译。一个案例。

管理员可以从后端编辑语言级别表,该表可以包含多个项目,如:基本、高级、流利、mattern。。。在不久的将来,它可能会是另一种类型。管理员进入后端并添加一个新级别,它会将其排序到正确的位置。。但是我如何为最终用户处理所有的翻译呢?

数据库国际化的另一个问题是,对于用户研究来说,从美国到英国再到德国......在每个国家,他们都有自己的水平(这可能相当于另一个,但最终是不同的)。计费呢?

你是如何在大范围内对此进行建模的?

共有2个答案

朱俭
2023-03-14

之前关于此主题的一些StackOverflow问题:

  • 多语言数据库设计的最佳实践是什么?
  • 保存多语言数据的最佳数据库结构是什么?
  • 多语言数据库的模式
  • 如何使用ORM的多语言数据库模式

一些有用的外部资源:

  • 创建多语言网站:数据库设计

最好的方法通常是,为每个现有表创建一个新表,将文本项移动到其中;新表的PK是旧表和语言的PK。

在您的情况下:

>

您现有的表可能如下所示:

+----+-------+---------+
| id | price | type    |
+----+-------+---------+
|  1 |   299 | basic   |
|  2 |   299 | advance |
|  3 |   399 | fluent  |
|  4 |     0 | mattern |
+----+-------+---------+

然后变成两张表:

+----+-------+   +----+------+-------------+
| id | price |   | id | lang | type        |
+----+-------+   +----+------+-------------+
|  1 |   299 |   |  1 | en   | basic       |
|  2 |   299 |   |  2 | en   | advance     |
|  3 |   399 |   |  3 | en   | fluent      |
|  4 |     0 |   |  4 | en   | mattern     |
+----+-------+   |  1 | fr   | élémentaire |
                 |  2 | fr   | avance      |
                 |  3 | fr   | couramment  |
                 :    :      :             :
                 +----+------+-------------+

数据库国际化的另一个问题是,用户研究可能因美国和英国的不同而有所不同。。。在每个国家,它们都有自己的水平(可能与另一个国家相当,但最终不同)。那账单呢?

所有本地化都可以通过类似的方法实现。不只是将文本字段移动到新表中,您可以移动任何可本地化的字段——只有所有地区通用的字段才会保留在原始表中。

封锐藻
2023-03-14

以下是我设计数据库的方法:

DB Designer Fork的可视化

i18n表只包含一个PK,因此任何表都只需引用这个PK即可将字段国际化。然后,表translation负责将这个通用ID与正确的翻译列表链接起来。

locale。id_locale是一个VARCHAR(5)来管理enen_USISO语法。

货币。id_currency是一个字符(3),用于管理ISO 4217语法。

你可以找到两个例子:页面时事通讯。这两个由管理员管理的实体都需要国际化其字段,分别是标题/描述主题/内容

下面是一个查询示例:

select
  t_subject.tx_translation as subject,
  t_content.tx_translation as content

from newsletter n

-- join for subject
inner join translation t_subject
  on t_subject.id_i18n = n.i18n_subject

-- join for content
inner join translation t_content
  on t_content.id_i18n = n.i18n_content

inner join locale l

  -- condition for subject
  on l.id_locale = t_subject.id_locale

  -- condition for content
  and l.id_locale = t_content.id_locale

-- locale condition
where l.id_locale = 'en_GB'

  -- other conditions
  and n.id_newsletter = 1

请注意,这是一个规范化的数据模型。如果你有一个巨大的数据集,也许你可以考虑去规范化它来优化你的查询。您还可以使用索引来提高查询性能(在某些数据库中,外键会自动索引,例如MySQL/InnoDB)。

 类似资料:
  • 问题内容: 我需要为将是多语言的Web应用程序创建大型DB模型。 我每次都在思考如何做到这一点时,一个疑问就是我如何解决一个字段的多个翻译问题。一个案例。 管理员可以从后端编辑的语言级别表可以有多个项目,例如:基本,高级,流利,重要…在不久的将来,它将是另一种类型。管理员转到后端并添加一个新级别,它将在正确的位置进行排序。.但是,我如何为最终用户处理所有翻译? 数据库国际化的另一个问题是,对于用户

  • 问题内容: 我正在开发一种多语言软件。就应用程序代码而言,可本地化性不是问题。我们可以使用特定于语言的资源,并拥有与之配合使用的各种工具。 但是,定义多语言数据库架构的最佳方法是什么?假设我们有很多表(100个或更多),每个表可以有多个可以本地化的列(大多数nvarchar列应该可以本地化)。例如,其中一个表可能包含产品信息: 我可以想到三种支持NAME和DESCRIPTION列中的多语言文本的方

  • 我们正忙于一个需要支持多种语言的CakePHP项目。但有一个问题....有些页面不支持其他语言。因此,有西班牙网页,需要隐藏的意大利版本的网站。在CakePHP中对此有什么更好的解决方案? 只要您切换语言,我们就可以切换数据库,但问题是,作为用户,我们将错过重要的数据,如果我们这样做的话。如果只搜索西班牙文、意大利文、德文、英文、荷兰文和瑞典文的文章,可能会使数据库负荷过重。或者如果我们索引语言栏

  • 问题内容: 我有一个需要支持多语言界面的应用程序,确切地说是五种语言。对于接口的主要部分,可以使用标准的Res​​ourceBundle方法来处理。 但是,数据库包含许多表,这些表的元素包含人类可读的名称,描述,摘要等。必须有可能以所有五种语言输入每一个。 虽然我想我可以简单地在每个表上都有字段 我认为在编写代表每个表的bean时,这会导致大量的很大程度上相同的代码。 从纯粹面向对象的角度来看,解

  • 问题内容: 我正在构建一个应用程序,它将需要提供多种语言和区域设置。 我的问题不是纯粹的技术问题,而是关于架构以及人们在生产中实际用来解决此问题的模式。我在那里找不到任何“食谱”,所以我转向了我最喜欢的问答网站:) 这是我的要求(它们实际上是“标准”): 用户可以选择语言(平凡) 更改语言后,界面应自动翻译成新选择的语言 我现在不太担心格式化数字,日期等的问题,我想要一个简单的解决方案来只翻译字符

  • 我正在构建一个应用程序,它需要有多种语言和地区。 我的问题不是纯粹的技术问题,而是关于架构,以及人们在生产中实际使用的模式来解决这个问题。我在任何地方都找不到这方面的“食谱”,所以我转向我最喜欢的问答网站:) 以下是我的要求(它们实际上是“标准”): 用户可以选择语言(普通) 更改语言后,界面应自动转换为新的选定语言 我不太担心格式化数字、日期等。目前,我想要一个简单的解决方案,只翻译字符串 以下