我有一个关于将数据放入 MySql 数据库的问题。我想创建 web 应用程序的产品列表类型，其中应该有几个字段，例如：名称（多语言字段，每种语言最多包含 256 个字符）、重量、宽度、高度、颜色、材料（以及其他一些应该仅包含数字，不必为每种语言进行更改）。所以我很累，我不知道如何正确处理这个任务。
我可以为我的所有数据使用单个表并为新语言创建新列，但是当开发人员尝试更改数据库的宽度或高度信息时会出现问题。所以他/她将不得不为所有语言更改这个单一参数。
我可以使用 2 个表，1 个用于多语言“名称”，另一个用于“产品”，其中第一个表中的 1 个字段将指示第二个表的 ID。在这种情况下，如果开发人员需要更改某些参数，他/她将只更改“产品”表中的 1 个字段。
我知道这个问题可能看起来很主观，但认为其他一些尝试创建多语言网络应用程序的人，比如我的，会发现答案很有用。
PS对不起我的英语水平
使用单列进行多个翻译的 ID 标记部分听起来很合理。然后，您可以拥有一个集中式服务器来存储应用程序特定的翻译文件，该文件始终与 id 同步以处理不同类型的客户端。任何客户端都应该能够使用自定义调用获取特定的翻译数据。这种机制可以很容易地利用缓存优化，并始终保证最新的翻译。
像这样的数据库列的国际化可能会变得棘手，而且确实没有“唯一的方法”。
在您的示例中，将名称分解为单独的表似乎是良好规范化的直接案例 - 我当然不会考虑复制整行只是为了翻译一列。但是，最终翻译的列越多，这种方法就会变得笨拙 - 在极端情况下，对于原始表中的每一列，您现在都有一个新表，而您的原始表的存在只是为了将它们放在一起。（关系数据库理论家喜欢这样的模式 - 查找 5NF 和 6NF - 但实际尝试使用数据库的人可能并不热衷于使用这么多JOINs）。
另一种方法是有一个大的文本字符串表，每个文本字符串都存储有唯一的 ID + 语言，然后通常会有一VarChar列，而是将相关 ID 存储在翻译表中。或者，您可以让翻译表直接存储每个字符串的上下文（例如表、列名和主键）。这导致数据库不那么“杂乱”的感觉，但是文本字符串表在数据建模方面相当奇怪：它们彼此之间没有连接，期望成为字符串。
我曾尝试过另一种解决方案，几年前我在这篇博文中将其称为“原子翻译”（顺便说一下，这篇博文还包含有关我刚刚提到的方法的更多细节）。我的想法是，与其将其视为规范化问题，不如将其视为数据类型问题：产品名称是单个信息，而翻译只是单个值的方面。实际上，与其将数据拆分为多个表，不如将其全部压缩到原始列中。我的具体实现是针对 PostgreSQL，所以我不知道这在 MySQL 中有多实用，如果类型与 DBMS 没有很好地集成，性能方面会出现一些棘手的问题，但我还没有发现基本方法的缺陷。