MySQL数据库设计与国际化

Question

我将开始开发一个中等规模的应用程序，并计划它的数据库设计。 有一件事我不确定，那就是： 我将有许多需要国际化的表，例如："membership_options, gender_options, language_options 等"

这些表中的每一个都将共享常见的 i18n 字段，如："title, alternative_title, short_description, description"

在您看来，哪种方法最好？ 为每个需要它们的表创建具有相同字段的 i18n 表？

还是像这样做：

Membership table     Gender table
----------------     --------------
id | created_at       id | created_at
1  -  22.03.2001       1 - 14.08.2002
2  -  22.03.2001       2 - 14.08.2002


General translation table
-------------------------
record_id | table_name | string_name | alternative_title| .... |id_language
 1        - membership   regular         null                     1 (english)
 1        - membership   normale         null                     2 (italian)
 1        - gender       man             null                     1(english)
 1        -gender        uomo           null                      2(italian)

这样可以避免我重复说同样的话：

membership_translation table
-----------------------------
membership_id | name | alternative_title | id_lang
1               regular  null             1
1               normale  null             2

gender_translation table
-----------------------------
gender_id | name | alternative_title | id_lang
1           man     null                1
1           uomo    null                2

等等，所以我可能会减少数据库表的数量，但我不确定性能如何。我不是很擅长数据库设计，请告诉我。

- Some name

---

可能是多语言数据库架构的重复问题。 - Maxime Pacary

Answer 1

我见过的最常见的做法是使用两个表，membership和membership_ml，其中一个存储基本值，另一个存储本地化字符串。这类似于你的第二个选项。我看到的大多数系统都是这样设计的，因为它们一开始并没有考虑国际化，所以额外的 _ml 表稍后才被“添加”上去。

我认为更好的选择与你的第一个选项类似，但有些不同。您将拥有一个中央表来存储所有翻译，但是您不会在其中放置表名和字段名，而是使用令牌和一个中央的“内容”表来存储所有翻译。这样，如果需要，您可以强制执行基本表中的令牌和内容表中的翻译之间的某种 RI。

实际上，我曾经问过一个问题，关于这个问题，所以你可以查看那里获取更多信息（而不是在此重新粘贴模式示例）。

- Eric Petroelje

Answer 2

我认为最好的解决方案是将翻译保留在不同的表格中。这种方法使用了开源的Open Cart，您可以查看它处理问题的方式。另一个信息来源在这里 "http://www.gsdesign.ro/blog/multilanguage-database-design-approach/"，特别是评论部分。

- Christoforos