开发者社区> 问答> 正文

动态创建的水平扩展表,而不是许多连接,以提高性能

考虑一个产品表,其中一些信息(例如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

由于没有所有繁琐的连接,此水平扩展的桌子是否会提供更多性能?

展开
收起
祖安文状元 2020-01-03 16:27:49 526 0
1 条回答
写回答
取消 提交回答
  • 显然,当您查询数据时,预计算值将是性能上的胜利。您必须权衡成本:

    维护未旋转的表将有些昂贵。 当添加新语言时,它将特别昂贵。 您可能由于汇总表的构建滞后而导致数据完整性问题。 维护触发器,存储过程或汇总表的任何内容都会使代码库复杂化。 也就是说,left join使用正确的索引,您的s应该不会特别昂贵。我首先要研究使用您描述的基本表的解决方案。只有到那时,我才会考虑汇总数据的选项。

    2020-01-03 16:28:01
    赞同 展开评论 打赏
问答地址:
问答排行榜
最热
最新

相关电子书

更多
动态、高效,蚂蚁动态卡片的内核逻辑 立即下载
事务、全局索引、透明分布式 立即下载
存储分层企业数据存储类型选择与优化 立即下载

相关实验场景

更多