为多语言内容设置数据库的最实用方法是什么？

Question

我仍在学习MySQL，并且在一个需要多语言内容的新项目中工作时，我偶然发现了一个最实际的方法来设计支持该功能的数据库，同时又是一个支持该功能的问题。最有效的数据库设置。

表content_quote：

+--------------+-----------------------+------+-----+---------------------+-----------------------------+
| Field        | Type                  | Null | Key | Default             | Extra                       |
+--------------+-----------------------+------+-----+---------------------+-----------------------------+
| quote_id     | int(11) unsigned      | NO   | PRI | NULL                | auto_increment              |
| url_slug     | varchar(255)          | NO   |     | NULL                |                             |
| author_id    | mediumint(8) unsigned | NO   |     | NULL                |                             |
| quote        | mediumtext            | NO   |     | NULL                |                             |
| category     | varchar(15)           | NO   |     | NULL                |                             |
| likes        | int(11) unsigned      | NO   |     | 0                   |                             |
| publish_time | datetime              | NO   |     | 0000-00-00 00:00:00 | on update CURRENT_TIMESTAMP |
| locale       | char(5)               | NO   |     | NULL                |                             |
+--------------+-----------------------+------+-----+---------------------+-----------------------------+

现在，我可以在locale字段中拥有一个标准的语言环境值，例如en-US，但是我有很多这样的表，而且我不确定什么是正确的路径，要么保留它或创建一个locale表来存储所有语言环境，并使用外键将当前的locale字段更改为tinyint 2并转到存储所有语言环境的新表。

示例：

+-----------+------------------+------+-----+---------+-------------------+
| Field     | Type                | Null | Key | Default | Extra          |
+-----------+------------------+------+-----+---------+-------------------+
| locale_id | tinyint(2) unsigned | NO   | PRI | NULL    | auto_increment |
| locale    | char(50)            | NO   |     | NULL    |                |
+-----------+------------------+------+-----+---------+-------------------+

除了答案本身之外，我还想知道两种方法的优点/缺点。

Answer 1

新locales表的优缺点（当不使用locales表时，它们会互换）：

优势

• 添加一些可能尚未使用的语言环境的列表。它允许您以某种形式创建可用区域的下拉列表。
• 防止输入错误，因为只有一个en_US值可用。

缺点

一直在新表上使用
• JOIN，只是为了获得en_US之类的字符串。

---

请记住，空间不会成为问题。不要试图根据5个字符对较小的int大小做出决定。