我想存储用户提供的内容的翻译。
我见过一些应用程序在每个语言环境中存储单独的翻译记录，但是 我想通过序列化翻译将所有翻译存储在记录中，我的意思是
$post_title=serialize(['en_US'=>$enUS['title'], 'fr_FR'=>$frFR['title']]);
$post_content=serialize(['en_US'=>$enUS['conttent'], 'fr_FR'=>$frFR['conttent']);
$sql="INSERT INTO `posts` (`title`, `content`) VALUES(:post_title, :post_content)"
这是一种不好的做法吗？
答案 0 :(得分：1)
假设（从您的INSERT查询中）您正在使用关系数据库，它可能被认为是一种不好的做法，因为：
时间和内存开销：要以任何语言加载帖子，您必须查询$post_title和$post_content这些是所有语言的序列化数据因此，您的数据库查询结果将具有更大的内存占用。然后你必须反序列化字段以获得所需语言的内容，如果前端设计不需要它，这也意味着额外的周期和不必要的开销;即，您没有同时以所有可用语言显示帖子。
Concurrency ：如果两位翻译人员将同一帖子的翻译更新为同时 ，该怎么办？
打破不透明度：正如其中一条评论中所提到的，在这种情况下，序列化的另一个问题是破坏数据库接口提供的预期抽象和封装。在处理本地化数据时，这可能不是一个大问题，但如果您的DBMS为您提供列级权限，那么序列化一列中的所有内容将阻止您使用该功能。
数据建模不一致：在这种情况下使用序列化，概念数据模型（具有多种语言的发布内容的网站）最终变得不连贯使用逻辑数据模型（$post_content不是发布内容所需的语言）。简单地说，通过查看数据模型，我们不能说多语言网站会使用这些表格。
i18n问题：在一列中将各种语言混合为序列化值限制了对内容使用多种编码的可能性;例如在Shift-JIS中保留日语，在Latin1中保留德语，在UTF8中保留其他所有内容。此外，它还可以在不对数据进行反序列化的情况下更加难以检查mojibake或其他编码问题。
如果出现以下情况，可以认为这是一个很好的解决方法：