0

I'm starting a project for a new global website with a lot of information. All this information must be localized. I build quite some sites and most of them are only partial in more than one language, but never did something with so much localization.

Assume we have the following data:

Country, City, Store, Product and Product producer.

In the entities Store, Product and Product producer it is possible to have the data localized. The language of the country is mandatory, but next to that N extra languages can be added. This is used to show the information to people of other countries and also I need to search about this.

My initial idea is to create a parent table per localized table with just an id and maybe some metadata that is non localizable and then create a child table with a reference to the parent table, a country code and the localized fields.

This structure potentially results in joins and thus could have a bad influence on performance. Does anyone has experience with this structure? Are there things I should take into consideration? Is there an other way of doing this better?

4

1 回答 1

1

首先，我不担心在混合性能方面加入一些连接。正如我们所说，过早优化是万恶之源。 首先创建一个干净的设计，然后再考虑性能。

您真正需要做的是考虑您正在本地化的确切内容以及原因。我们在 LedgerSMB 中所做的正是您所建议的，即带有事实的表格（如果您愿意的话），然后是带有翻译的表格。

保持一切正常运行的关键是考虑减少来回发送的实际查询数量。运行一个连接 60 个左右的字符串然后你的应用程序处理它们是一回事。性能方面，向数据库发送 60 个不同的查询以分别提取 1 个字符串要糟糕得多。

还将您的主要字符串保存在 .po 文件或类似文件中，并为这些文件使用本地化框架。这不是非此即彼的事情。

于 2013-03-24T13:13:14.510 回答