我正在为一个拥有大量信息的新全球网站启动一个项目。所有这些信息必须本地化。我建立了一些网站，其中大多数只是部分使用多种语言，但从未做过如此多的本地化。
假设我们有以下数据：
国家，城市，商店，产品和产品生产商。
在实体商店，产品和产品生产商中，可以对数据进行本地化。该国家/地区的语言是强制性的，但旁边可以添加N种额外语言。这用于向其他国家的人们显示信息，我也需要搜索这个。
我最初的想法是为每个本地化的表创建一个父表，只有一个id和一些不可本地化的元数据，然后创建一个子表，其中包含对父表的引用，国家代码和本地化字段。 / p>
此结构可能会导致连接，从而可能对性能产生不良影响。有没有人有这种结构的经验？有什么我应该考虑的事情吗？还有其他方法可以做得更好吗？
答案 0 :(得分：1)
首先，我不担心在混合性能方面投入一些联接。正如我们所说，过早优化是万恶之源。首先创建一个干净的设计，然后担心性能。
你真正需要做的是仔细考虑你的本地化和原因。我们在LedgerSMB中所做的正是您所建议的，即如果您愿意，可以使用事实表，然后使用翻译表。
保持一切运行良好的关键是考虑减少来回发送的实际查询的数量。运行一个连接，拉出60个左右的字符串然后你的应用程序处理它们是一回事。在性能方面，如果向数据库发送60个不同的查询以分别提取1个字符串，那么很多更糟糕。
还要将主要字符串保存在.po文件等中，并使用本地化框架。这不是一个或两件事。