当我用语言实现product_description表时，我遇到了一些问题。
我的过程是我有默认表product_description_en来存储描述，当客户端安装新语言（中文）时，php脚本将创建新表product_des_ch然后将所有默认数据（从英语表中）放入新的创建了table.then客户端可以更新。 我的问题是
2.如果我们对所有语言使用相同的表（记录大约为500,000），那么每个性能问题是否存在 3.存储大量记录的最佳方式是什么，我的意思是相同的表格或单独的表格。
感谢名单 AZ
更新： 这是英语表和日本的示例product_description表结构。您对此表的看法是什么（我们将所有记录存储在同一个表中，当客户端插入不同语言的新记录时只插入新记录），是否有任何反馈？
+---------------------------------------------------------------------------+
| product_id | name | desc | meta_name | meta_desc | key_words | lan_code |
+---------------------------------------------------------------------------+
| 1 | A | D| m1 | m_d1 | k1 | en |
+---------------------------------------------------------------------------+
| 1 | A | D| m2 | m_d2 | k2 | jp |
+---------------------------------------------------------------------------+
答案 0 :(得分：2)
基本的RDBMS设计智慧会在动态改变表结构的任何东西上放置一个巨大的红旗。关系数据库非常灵活，可以处理几乎任何情况而无需采取这些措施。
我对结构的建议是创建一个Languages表来存储可用的语言，然后创建一个Phrases表来存储所有可用的短语。然后使用Translations表将这些短语的实际翻译提供为可用语言。可能看起来像这样的东西：
Language
+----+---------+
| id | name |
+----+---------+
| 1 | English |
| 2 | Chinese |
+----+---------+
Phrase
+----+-------------+
| id | label |
+----+-------------+
| 1 | header |
| 2 | description |
+----+-------------+
Translations
+-------------+-----------+-----------------+
| language_id | phrase_id | translation |
+-------------+-----------+-----------------+
| 1 | 1 | Header |
| 1 | 2 | Description |
| 2 | 1 | 头 |
| 2 | 2 | 描述 |
+-------------+-----------+-----------------+
对于中小型数据库，即使使用默认数据库配置，也不应存在任何性能问题。如果你达到了巨大的规模（你在数据库中以数TB为单位），你可以通过多种方式优化数据库，以保持性能水平。