将MySQL视图转换为Postgres

时间:2015-07-18 08:08:44

标签: mysql sql postgresql laravel-migrations

我继承了将生产MySQL数据库转换为Postgres的需求。使用简单的SQL语句创建表/函数(使用Navicat生成半自动转换),大多数情况下处理都没有问题,但现在我遇到了转换有点复杂视图的问题。

研究表明,这可能是由于两个DB如何处理子查询(WHERE语句)的差异,也许它只是一个语法差异。这里的业务逻辑是未知的,因为代码库已从其他开发人员继承。

运行以下内容(使用Laravel迁移/ PHP脚本):

SELECT 
parent.is_owner AS is_owner,
parent.brand AS first_name,
parent.id AS id,
(SELECT count(c.id)
 FROM campaigns c
 WHERE((
       (c.user_id = parent.id)
       OR
       (c.user_id = child.id)
       )
       AND
       (c.campaign_status_id = 4)
))
AS current_campaigns,
(SELECT count(c.id)
    FROM campaigns c
    WHERE
        ((
        (c.user_id = parent.id)
        OR (c.user_id = child.id)
        )
        AND (c.campaign_status_id = 5)
))
AS past_campaigns,
(SELECT count(c.id)
    FROM campaigns c
    WHERE
        ((
         (c.user_id = parent.id)
         OR (c.user_id = child.id))
         AND (c.campaign_status_id = 2)
        ))
    AS pending_campaigns,
(SELECT count(c.id)
    FROM    campaigns c
    WHERE ((
            (c.user_id = parent.id)
            OR (c.user_id = child.id)
            )
            AND (c.invoice_status = '1')
        ))
    AS past_invoices
FROM ((users parent LEFT JOIN campaigns mc ON
     ((parent.id = mc.user_id)))
    LEFT JOIN users child ON ((child.parent_owner = parent.id)
    ))
WHERE
(
    (parent.is_owner = 1)
    OR (child.is_retailer = 1)
)
GROUP BY parent.id
ORDER BY parent.brand

...触发错误

SQLSTATE[42803]: Grouping error: 7 ERROR:  subquery uses ungrouped column "child.id" from outer query
  LINE 1: ...c where (((c.user_id = parent.id) or (c.user_id = child.id)) ...

有人可以建议如何格式化这样,以便Postgres运行子查询吗?

顺便说一下,Laravel迁移脚本中使用的PHP代码是:

...

DB::unprepared("CREATE VIEW client AS
select parent.is_owner AS is_owner,parent.brand AS first_name,parent.id AS id
   ,(select count(c.id) from campaigns c where (((c.user_id = parent.id) or (c.user_id = child.id)) and (c.campaign_status_id = 4))) AS current_campaigns
   ,(select count(c.id) from campaigns c where (((c.user_id = parent.id) or (c.user_id = child.id)) and (c.campaign_status_id = 5))) AS past_campaigns
   ,(select count(c.id) from campaigns c where (((c.user_id = parent.id) or (c.user_id = child.id)) and (c.campaign_status_id = 2))) AS pending_campaigns
   ,(select count(c.id) from campaigns c where (((c.user_id = parent.id) or (c.user_id = child.id)) and (c.invoice_status = '1'))) AS past_invoices
from ((users parent
left join campaigns mc on((parent.id = mc.user_id)))
left join users child on((child.parent_owner = parent.id)))
where ((parent.is_owner = 1) or (child.is_retailer = 1))
group by parent.id
order by parent.brand;");

更新,修复:

辉煌。非常好的输入来自所有人。

@patrick和@ErwinBrandstetter的解决方案都有效。我会支持Patrick在这里,因为我在这方面的作用是转换系统" as-is"。将来可能有重构的余地,但在这个阶段我觉得混淆(或改进)别人的胶带解决方案是有风险的(即代码库在某些地方似乎过于复杂,没有任何迹象表明文档,我不愿意在没有更多关于业务逻辑的背景信息的情况下蠢蠢欲动或尝试核心改进。我怀疑模型的某些部分可能需要进行大修,所以[sic] -fix在这里很受欢迎。

我怀疑一些点击 - jiggery可能会产生原始查询...试图给原始开发者带来疑问的好处,并假设有一些业务压力要求快速(即模糊)转向。复杂的SQL不是我的强项,但我很高兴我的直觉是正确的,查询开始时是不必要的复杂。也许这个视图是一个无计划的螺栓 - 首先不是设计的。明智与否,我可能试图用基于ORM的方法解决问题。

我最后一分钟在这个项目上运行清理以重新启动(原始开发人员是#34;放开"),所以我正在处理一个充满未知功能的大多数未记录的代码库。按原样运行伞兵。值得庆幸的是,这个视图问题出现到最后一块拼图。谢谢: - )

2 个答案:

答案 0 :(得分:6)

哦,我的,哦,我的。毫无疑问,开发人员在他的右手无名指中有一个抽搐,因为这句话有不少于74个括号。以下是8个括号和14行而不是54行的结果:

SELECT 
  parent.is_owner AS is_owner,
  parent.brand AS first_name,
  parent.id AS id,
  sum(CASE WHEN c.campaign_status_id = 4 THEN 1 ElSE 0 END) AS current_campaigns,
  sum(CASE WHEN c.campaign_status_id = 5 THEN 1 ElSE 0 END) AS past_campaigns,
  sum(CASE WHEN c.campaign_status_id = 2 THEN 1 ElSE 0 END) AS pending_campaigns,
  sum(CASE WHEN c.invoice_status = '1' THEN 1 ElSE 0 END) AS past_invoices,
FROM users parent
LEFT JOIN users child ON child.parent_owner = parent.id
LEFT JOIN campaigns c ON c.user_id = parent.id OR c.user_id = child.id
WHERE parent.is_owner = 1 OR child.is_retailer = 1
GROUP BY parent.is_owner, parent.brand, parent.id
ORDER BY parent.brand;

没有子选择意味着此代码运行起来会更快。就像他在评论中提到的Wolph一样,选择列表中未包含在聚合函数中的每一列都必须出现在GROUP BY子句中,如SQL标准所规定,但是被MySQL忽略了。

使用CASE构造避免了子选择:列列表中的条件表达式求值。请注意,子选择中的过滤的重复子句现在作为JOIN子句执行,而campaigns中的一个相关列仅在主查询中按列进行评估。从1语句中发出0CASE并将其包含在sum()函数中是一个很好的技巧,可以在单个查询中执行多个不同的计数。

正如Wolph在下面的评论中指出的那样,该条款

sum(CASE WHEN c.campaign_status_id = 4 THEN 1 ElSE 0 END) AS current_campaigns

也可以更简洁地写成

sum((c.campaign_status_id = 4)::integer) AS current_campaigns

这可能比CASE语句快一些,因为在编写PostgreSQL的C语言中,boolean to integer强制转换不需要任何操作(布尔值在C中为1或0)。易读性肯定较少(更不用说使用两倍多的括号!)。

答案 1 :(得分:2)

问题中缺少解释,但可能的用例是:

计算每个用户拥有的广告系列数量"。用户可以拥有子用户,其活动应添加到父用户。

除了@Patrick decluttered in his demo令人难以置信的嘈杂语法之外,查询也是模棱两可的(并且可能完全错误):

如果我们可以假设:

  • 参照完整性:子用户仅引用现有父用户,并使用FOREIGN KEY约束强制执行。

  • 父母和子女被可靠地标记为is_owner / is_retailer,这些列只包含值01见下文。

此查询将完成此任务:

SELECT CASE WHEN u.is_retailer = 1 THEN u.parent_owner
            WHEN u.is_owner = 1    THEN u.id END        AS user_id
     , max(u.is_owner)                                  AS is_owner
     , max(u.brand) FILTER (WHERE u.is_owner = 1)       AS first_name
     , count(*) FILTER (WHERE c.campaign_status_id = 4) AS current_campaigns
     , count(*) FILTER (WHERE c.campaign_status_id = 5) AS past_campaigns
     , count(*) FILTER (WHERE c.campaign_status_id = 2) AS pending_campaigns
     , count(*) FILTER (WHERE c.invoice_status = '1')   AS past_invoices
FROM   users          u
LEFT   JOIN campaigns c ON u.id = c.user_id
                       AND (c.campaign_status_id IN (4, 5, 2) OR 
                            c.invoice_status = '1')  -- exclude irrelevant early
WHERE  1 IN (u.is_owner, u.is_retailer)  -- parent & child, may be redundant
GROUP  BY 1
ORDER  BY 2;

应该很快。一定要有大表的拟合指数 如果没有其他选择,这种情况是多余的:

   WHERE  1 IN (u.is_owner, u.is_retailer)

我使用了您的数据模型"按原样#34;但您可能应该只有boolean列:

  • is_childtrue代表儿童,false代表父母。
  • is_ownertrue代表所有者,false代表零售商。

使用Postgres 9.4中引入的新聚合FILTER 子句: