我仍在学习 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 | |
+--------------+-----------------------+------+-----+---------------------+-----------------------------+
现在我可以在语言环境字段中使用标准语言环境值，如 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 | |
+-----------+------------------+------+-----+---------+-------------------+
除了答案本身，我还想知道这两种方法的优点/缺点是什么。
最佳答案
新的 locales 表的优点和缺点(当不使用 locales 表时它们会被交换):
优势
- 添加可用语言环境列表(当某些语言环境可能尚未使用时)。它允许您以某种形式创建可用语言环境的下拉列表。
- 防止输入错误，因为只有一个
en_US值可用。
缺点
JOIN始终在新表上获取类似en_US的字符串。
请记住，空间不是问题。不要试图根据 5 个字符与微小的 int 大小做出决定。
关于mysql - 为多语言内容设置数据库的最实用方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51348508/