2015-04-03 46 views
0

我需要一点疯狂的单一查询目标的帮助,请不要确定GROUP BYSELECT是否适用于?PostgreSQL两个分组,但没有排序只有零价格列

下面的查询:

SELECT id_finish, description, inside_rate, outside_material, id_part, id_metal 
FROM parts_finishing AS pf 
LEFT JOIN parts_finishing_descriptions AS fd ON (pf.id_description=fd.id); 

返回的结果如下所示:

+-------------+-------------+------------------+--------------------------------+ 
| description | inside_rate | outside_material | id_part - id_finish - id_metal | 
+-------------+-------------+------------------+--------------------------------+ 
| Nickle  | 0   | 33.44   | 4444-44-44, 5555-55-55   | 
+-------------+-------------+------------------+--------------------------------+ 
| Bend  | 11.22  | 0    | 1111-11-11      | 
+-------------+-------------+------------------+--------------------------------+ 
| Pack  | 22.33  | 0    | 2222-22-22, 3333-33-33   | 
+-------------+-------------+------------------+--------------------------------+ 
| Zinc  | 0   | 44.55   | 6000-66-66      | 
+-------------+-------------+------------------+--------------------------------+ 

我需要的结果在下面的方式返回,但也有渔获:

  1. 我需要按inside_rateoutside_materialORDER BYdescription列,但不ORDER BY或按价格排序它们(inside_rateoutside_material是价格)。因此,我们知道,他们属于一个组,如果inside_rate为0或另一组如果outside_material为0

  2. 我需要ORDER BYdescriptiondesc二次他们每个组返回后。

  3. 我需要返回一个零件列表(由三个单独的列组成),以完成该内部/外部组/价格。

堆栈格式修复。

+-------------+-------------+------------------+--------------------------------+ 
| description | inside_rate | outside_material | id_part - id_finish - id_metal | 
+-------------+-------------+------------------+--------------------------------+ 
| Bend  | 11.22  | 0    | 1111-11-11      | 
+-------------+-------------+------------------+--------------------------------+ 
| Pack  | 22.33  | 0    | 2222-22-22, 3333-33-33   | 
+-------------+-------------+------------------+--------------------------------+ 
| Nickle  | 0   | 33.44   | 4444-44-44, 5555-55-55   | 
+-------------+-------------+------------------+--------------------------------+ 
| Zinc  | 0   | 44.55   | 6000-66-66      | 
+-------------+-------------+------------------+--------------------------------+ 

我的工作表和它们的数据类型:

       Table "public.parts_finishing" 
     Column  | Type |       Modifiers 
------------------+---------+------------------------------------------------------------- 
id    | bigint | not null default nextval('parts_finishing_id_seq'::regclass) 
id_part   | bigint | 
id_finish  | bigint | 
id_metal   | bigint | 
id_description | bigint | 
date    | date | 
inside_hours_k | numeric | 
inside_rate  | numeric | 
outside_material | numeric | 
sort    | integer | 
Indexes: 
    "parts_finishing_pkey" PRIMARY KEY, btree (id) 


          Table "public.parts_finishing_descriptions" 
    Column | Type |         Modifiers 
------------+---------+------------------------------------------------------------------ 
id not null | bigint | default nextval('parts_finishing_descriptions_id_seq'::regclass) 
date  | date | 
description | text | 
rate_hour | numeric | 
type  | text | 
Indexes: 
    "parts_finishing_descriptions_pkey" PRIMARY KEY, btree (id) 

第二个表的第一列是只是id。 (为什么我们仍然在处理2015年的1024静态宽度布局?)

我会制作一个SQL小提琴,尽管它拒绝为我加载,无论浏览器如何。

+0

请说明。 '由inside_rate列或outside_material列'组是不明确的。你提到一个'价格',但它既不在查询中,也不在结果中,也不在表格定义中。添加您的Postgres版本并提供*适当的*表格定义。在psql中复制'\ d parts_finishing'的输出 - 这是一种可靠的标准格式,胜过任何手动描述。什么是“堆栈格式修复”。应该是什么意思? – 2015-04-03 17:38:51

+0

@ErwinBrandstetter价格是我*应该从一开始就澄清的因特网/外部费率/材料,我的不好。 “堆栈格式修复”只是*有序列表和代码块之间的占位符*,因为Stack存在某种合并二者的错误。我想我已经得到了你现在要求的所有更新。 – John 2015-04-06 16:53:56

+0

@ErwinBrandstetter我意识到我可以将结果分成两个单独的PHP容器,所以这个问题不是超级重要的,但是如果你仍然想回答,我会将它添加到我计划最终发布的文档中。 – John 2015-04-06 17:12:20

回答

1

不完全确定我理解你的问题。可能看起来像这样:

SELECT pd.description, pf.inside_rate, pf.outside_material 
    , concat_ws(' - ', pf.id_part::text 
         , pf.id_finish::text 
         , pf.id_metal::text) AS id_part_finish_metal 
FROM parts_finishing pf 
LEFT JOIN parts_finishing_descriptions fd ON pf.id_description = fd.id 
ORDER BY (pf.inside_rate = 0)   -- 1. sorts group "inside_rate" first 
    , pd.description DESC NULLS LAST -- 2. possible NULL values last 
; 
+0

谢谢欧文!我不得不编辑它才能使它工作,但没有SQL小提琴的工作,这并不容易。我开始质疑“GROUP BY”子句的意义,因为它似乎从未在PostgreSQL中实际做过任何有用的事情。 – John 2015-04-07 15:17:32

+0

@John:哦,'GROUP BY'有很多用例... – 2015-04-07 16:40:40

+0

你有什么阅读建议吗?我现在的客户做生产,我很乐意能够扩大我的能力,以满足客户的需求。感谢您的洞察力,并且一般都很棒。 – John 2015-04-07 19:02:34

相关问题