PostgreSQL的最佳特性 你用了吗?

SQL语句通常不是很容易理解,特别是你阅读别人已经写好的语句。因此,很多人指出我们应该遵循在其他语言中遵循的原则,像加上注释和功能模块化。 我***注意到一个很多人都没有使用的Postgres关键特性,也就是 @timonk在AWS Re:Invent 大会关于数据仓库服务Redshift主题演讲时指出的一个特性。这个特性实际上使得SQL兼具了可读性和模块性。在以前,我回头阅读自己的几个月前的 SQL语句,通常很难理解,而现在我可以做到这一点。

这个特性就是CTEs,也就是公用表表达式,你有可能称做它为WITH 语句。和数据库中视图一样,它的主要好处就是,它允许你在当前事务中创建临时表。你可以大量使用它,因为它允许你思路清晰的构建模块,别人很容易就理解你在做什么。

让我们举个简单的例子

  1. WITH users_tasks AS ( 
  2.   SELECT 
  3.          users.email, 
  4.          array_agg(tasks.nameas task_list, 
  5.          projects.title 
  6.   FROM 
  7.        users, 
  8.        tasks, 
  9.        project 
  10.   WHERE 
  11.         users.id = tasks.user_id 
  12.         projects.title = tasks.project_id 
  13.   GROUP BY 
  14.            users.email, 
  15.            projects.title 

通过这样定义临时表users_tasks,我就可以在后面加上对users_tasks基本查询语句,像:

  1. SELECT * 
  2. FROM users_tasks; 

有趣的是你可以将它们连在一起。当我知道分配给每个用户的任务量时,也许我想知道在一个指定的任务上,谁因为对这个任务负责超过了50%而因此造成瓶颈。为了简化,我们可以使用多种方式,先计算每个任务的总量,然后是每人针对每个任务的负责总量。

  1. total_tasks_per_project AS ( 
  2.   SELECT 
  3.          project_id, 
  4.          count(*) as task_count 
  5.   FROM tasks 
  6.   GROUP BY project_id 
  7. ), 
  8.   
  9. tasks_per_project_per_user AS ( 
  10.   SELECT 
  11.          user_id, 
  12.          project_id, 
  13.          count(*) as task_count 
  14.   FROM tasks 
  15.   GROUP BY user_id, project_id 
  16. ), 

现在我们将组合一下然后发现超过50%的用户

  1. overloaded_users AS ( 
  2.   SELECT tasks_per_project_per_user.user_id, 
  3.   
  4.   FROM tasks_per_project_per_user, 
  5.        total_tasks_per_project 
  6.   WHERE tasks_per_project_per_user.task_count > (total_tasks_per_project / 2) 

最终目标,我想获得超负荷工作这的用户和任务的逗号分隔列表。我们只要简单地对overloaded_users和 users_tasks的初始列表进行join操作。放在一起可能有点长,但是可读性强。作为额外帮助,我又在每一层加了注释。

  1. --- Created by Craig Kerstiens 11/18/2013 
  2. --- Query highlights users that have over 50% of tasks on a given project 
  3. --- Gives comma separated list of their tasks and the project 
  4.   
  5. --- Initial query to grab project title and tasks per user 
  6. WITH users_tasks AS ( 
  7.   SELECT 
  8.          users.id as user_id, 
  9.          users.email, 
  10.          array_agg(tasks.nameas task_list, 
  11.          projects.title 
  12.   FROM 
  13.        users, 
  14.        tasks, 
  15.        project 
  16.   WHERE 
  17.         users.id = tasks.user_id 
  18.         projects.title = tasks.project_id 
  19.   GROUP BY 
  20.            users.email, 
  21.            projects.title 
  22. ), 
  23.   
  24. --- Calculates the total tasks per each project 
  25. total_tasks_per_project AS ( 
  26.   SELECT 
  27.          project_id, 
  28.          count(*) as task_count 
  29.   FROM tasks 
  30.   GROUP BY project_id 
  31. ), 
  32.   
  33. --- Calculates the projects per each user 
  34. tasks_per_project_per_user AS ( 
  35.   SELECT 
  36.          user_id, 
  37.          project_id, 
  38.          count(*) as task_count 
  39.   FROM tasks 
  40.   GROUP BY user_id, project_id 
  41. ), 
  42.   
  43. --- Gets user ids that have over 50% of tasks assigned 
  44. overloaded_users AS ( 
  45.   SELECT tasks_per_project_per_user.user_id, 
  46.   
  47.   FROM tasks_per_project_per_user, 
  48.        total_tasks_per_project 
  49.   WHERE tasks_per_project_per_user.task_count > (total_tasks_per_project / 2) 
  50.   
  51. SELECT 
  52.        email, 
  53.        task_list, 
  54.        title 
  55. FROM 
  56.      users_tasks, 
  57.      overloaded_users 
  58. WHERE 
  59.       users_tasks.user_id = overloaded_users.user_id 

CTEs通常不如经过精简优化过的SQL语句性能高。大多数差距小于一倍差距。对我而言,这种为了可读性作出的折中是毋庸置疑的。Postgres优化器以后肯定会针对这点变的更好。

多说一句,是的我可以用大约10-15行简短的SQL语句做同样的事情,但是你也许不能很快的理解它。当你碰到需要保证SQL做正确的事情时,可读性的优势就出来了。SQL语句总是有个结果,你对此毫无疑问。确保你SQL语句容易推理是保证正确性的关键。

原文链接:http://www.craigkerstiens.com/2013/11/18/best-postgres-feature-youre-not-using/

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/233582.html<

(0)
管理的头像管理
上一篇2025-04-20 16:56
下一篇 2025-04-20 16:58

相关推荐

  • 服务器防火墙硬件和软件哪个效果更好,怎么选

    在服务器防火墙的选型中,硬件防火墙与软件防火墙并非非此即彼,而是互补关系,对于追求高安全等级与稳定性的生产环境,采用硬件防火墙做网络层隔离,配合软件防火墙做主机层加固,是当前公认效果最好的组合方案,硬件防火墙与软件防火墙的核心差异性能与资源占用硬件防火墙依托专用ASIC芯片或FPGA处理数据包,转发延迟通常在微……

    2026-07-26
    0
  • 站群服务器做GEO的核心逻辑是什么?,怎么做

    站群服务器做SEO的核心逻辑,是通过独立IP和资源隔离,彻底切断站点间的关联性,让搜索引擎对每个网站进行独立评估,从而降低连带风险并提升整体排名效率,站群服务器的核心价值:独立性与隔离性IP独立性:为什么是命门搜索引擎在评估网站时,会记录IP地址,如果多个站点共享同一个IP,它们之间很容易被判定为同一主体控制……

    2026-07-26
    0
  • 弹性云服务器到底是什么意思怎么收费,多少钱一个月

    弹性云服务器(Elastic Cloud Server,ECS)是一种可随时调整计算资源的云服务器,收费方式以按需付费和包年包月为主,用户只需为实际使用的资源买单,什么是弹性云服务器弹性云服务器本质上是一台运行在云端、配置可以灵活调整的虚拟机,它不像物理服务器那样固定规格,你可以在业务高峰期快速增加CPU、内存……

    2026-07-26
    0
  • 黑洞解封到底是什么意思,需要多久才能恢复

    黑洞解封是指将被黑洞路由策略屏蔽的IP地址恢复正常通信的过程,恢复时间通常取决于攻击流量是否彻底停止,多数情况下在攻击停止后10分钟到24小时内自动解除,用户也可通过联系服务商手动加速解封,黑洞解封到底是什么用拟人化的方式理解,黑洞就是网络世界的“强制隔离区”,当某个IP地址遭遇大量异常流量,比如DDoS攻击……

    2026-07-26
    0
  • 站群服务器IP段怎么选最安全,有哪些注意事项

    选择站群服务器IP段的安全核心在于IP地址的独立性、机房的路由策略以及服务商的合规资质,一个可靠的IP段必须来自持牌自营机房,具备独立C段和清洗能力,才能避免被关联风险,为什么IP段选择决定站群安全搜索引擎对IP关联的识别算法近年来越来越精细,同一C段或广播域的IP,爬虫通过反向DNS、路由跳数等特征很容易判断……

    2026-07-26
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注