Php 多语言翻译模块的数据库模型

我需要为后端模块设计一个db模型，用户可以将页面内容翻译成多种语言。将要翻译的内容包括基本单词、短语、链接名、标题、字段名和字段值。它们也应该分组，以便我可以按组名找到它们。例如，如果页面上有一个选择字段，使用不同的颜色作为选项，那么我应该能够按组名选择所有字段

因此，以下是我目前的情况：

lang
+----+---------+
| id |  name   |
+----+---------+
|  1 | english |
|  2 | german  |
+----+---------+

lang_entity
+----+------------+-------------+-------+-------+
| id |   module   |    group    | name  | order |
+----+------------+-------------+-------+-------+
|  1 | general    |             | hello |     0 |
|  2 | accounting | colorSelect | one   |     1 |
|  3 | accounting | colorSelect | two   |     2 |
|  4 | accounting | colorSelect | three |     3 |
+----+------------+-------------+-------+-------+

lang_entity_translation
+----+---------+----------------+-------------+
| id | lang_id | lang_entity_id | translation |
+----+---------+----------------+-------------+
|  1 |       1 |              1 | Hello       |
|  2 |       2 |              1 | Guten tag   |
|  3 |       1 |              2 | One         |
|  4 |       2 |              2 | Ein         |
|  5 |       1 |              3 | Two         |
|  6 |       2 |              3 | Zwei        |
|  7 |       1 |              4 | Three       |
|  8 |       2 |              4 | Drei        |
+----+---------+----------------+-------------+

所以lang表包含不同的语言

表lang_实体具有可翻译为不同语言的实体。 模块行只是按照后端翻译模块中的页面模块对它们进行分组。这也使我有可能为不同的模块使用相同名称的实体。 所提到的组对于选择和可能使用多个值的其他一些地方是必需的。这还提供了一个选项，允许用户在一个组中添加和订购实体

表lang_entity_translation保存每种语言中每个实体的翻译

所以我的问题是，这种设计有明显的缺陷吗？你能推荐一些不同的吗

还有一个额外的问题：我真的不喜欢lang_实体表名，您是否有更好的想法来使用一个表名来保存所有已翻译的单词/短语？：）

---

编辑：类似，但不是重复。链接的问题是关于翻译动态产品，并为每种翻译类型提供一个单独的表。我说的是翻译整个页面的内容，包括单个表中的组。

我们也有类似的情况。这是7年前的事了。 我们有不同语言的专栏。就像我们的名字一样 我们有7-10种语言

所有语言的名称都有一个共同的id

根据UI中的语言选择，我们在存储过程中将语言代码传递到后端，并将其附加到列名中

---

例如，如果选择了English，我们将传递“Eng”，并将列名形成为name_Eng并获取数据。我们使用的是动态查询。

我们遇到了类似的情况。这是7年前的事了。 我们有不同语言的专栏。就像我们的名字一样 我们有7-10种语言

所有语言的名称都有一个共同的id

根据UI中的语言选择，我们在存储过程中将语言代码传递到后端，并将其附加到列名中

---

例如，如果选择了English，我们将传递“Eng”，并将列名形成为name_Eng并获取数据。我们使用的是动态查询。

我不理解

lang\u entity

的

order

列，但我可能不需要这样做

设置看起来正常，但请确保将外键约束从

lang\u entity\u translation

添加到

lang\u entity

和

lang\u entity

---

至于命名，我会调用表

phrase

或

translateable

我不理解

lang\u entity

的

顺序

列，但我可能不需要这样做

设置看起来正常，但请确保将外键约束从

lang\u entity\u translation

添加到

lang\u entity

和

lang\u entity

---

至于命名，我会称该表为

短语

或

可翻译

请仅标记您正在使用的RDBMS。可能重复的请仅标记您正在使用的RDBMS。可能重复的我认为这不是一个聪明的设计。您可以在可以避免的地方强制执行动态SQL。每次添加/删除新语言时，都必须更改表结构。我认为，如果您有一组可以保证永远不会更改的语言，那么这是一个可以接受的解决方案。但对我来说，用户可以添加/删除语言，这样就不起作用了。我认为这不是一个聪明的设计。您可以在可以避免的地方强制执行动态SQL。每次添加/删除新语言时，都必须更改表结构。我认为，如果您有一组可以保证永远不会更改的语言，那么这是一个可以接受的解决方案。但对我来说，用户可以添加/删除语言，这样就不起作用了。这是一个有点糟糕的例子，因为我有0,1,2,3个。但关键在于每个组都有自己的顺序，这样用户就有可能编辑它或者在中间添加一些东西。例如，colorSelect组值将进入下拉选择字段，顺序决定它们在该字段中的顺序。如果一个元素不在一个组中，它的emtpy或0值与第一个相同。关于命名，我喜欢你建议的translateable这个词，而不是lang_entity。但是你会将语言实体翻译命名为翻译还是可翻译翻译？我倾向于将它们命名为可翻译和可翻译。这是一个有点糟糕的例子，因为我在它们后面有0,1,2,3。但关键在于每个组都有自己的顺序，这样用户就有可能编辑它或者在中间添加一些东西。例如，colorSelect组值将进入下拉选择字段，顺序决定它们在该字段中的顺序。如果一个元素不在一个组中，它的emtpy或0值与第一个相同。关于命名，我喜欢你建议的translateable这个词，而不是lang_entity。但是你会将语言实体翻译命名为翻译还是可翻译翻译？我倾向于将它们命名为可翻译和可翻译。