考虑一个产品表,其中一些信息(例如TITLE和BRAND)以多种语言保存在一个巨大的“翻译”表中。
tblTranslations
ROW_ID
COL_NAME
LANG
VALUE
由于将使用的语言是动态的,因此不能在主表中保留所需语言的标题,例如TITLE_EN,TITLE_FR。因此,我们遇到了如下复杂的查询:
SELECT
P.ID,
(...)
T1.VALUE AS TITLE,
T2.VALUE AS BRAND
FROM tblProducts P
-- first join for TITLEs in the selected language
LEFT JOIN tblTranslations T1 ON T1.ROW_ID = P.ID AND T1.COL_NAME = 'TITLE' AND T1.LANG = '{$selectedLang}'
-- second join for BRANDs
LEFT JOIN tblTranslations T2 ON T2.ROW_ID = P.ID AND T2.COL_NAME = 'BRAND' AND T2.LANG = '{$selectedLang}'
WHERE (...)
这是一个过于简化的示例,我们的现实生活查询中还有许多其他表针对动态属性等进行了联接,这使我们的网站开始在地面上爬行。
我的问题:动态创建表并将其仅用于SELECT更好吗?该表将在更新主数据时更新,并在添加新语言时重新创建。
tblProductsDynamic
ID
TITLE_EN
TITLE_FR
BRAND_EN
BRAND_FR
(...)
SELECT
ID,
TITLE_{$selectedLang} AS TITLE,
BRAND_{$selectedLang} AS BRAND
FROM tblProductsDynamic
由于没有所有繁琐的连接,此水平扩展的桌子是否会提供更多性能?
显然,当您查询数据时,预计算值将是性能上的胜利。您必须权衡成本:
维护未旋转的表将有些昂贵。 当添加新语言时,它将特别昂贵。 您可能由于汇总表的构建滞后而导致数据完整性问题。 维护触发器,存储过程或汇总表的任何内容都会使代码库复杂化。 也就是说,left join使用正确的索引,您的s应该不会特别昂贵。我首先要研究使用您描述的基本表的解决方案。只有到那时,我才会考虑汇总数据的选项。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。