第三个INNER / LEFT连接和计数不匹配的问题

时间:2018-07-18 19:50:44

标签: sql sql-server join

我有一个查询,该查询为我提供了某些字段,例如JOB_TYPE,WORK_SUBTYPE和JOB_TYPE。我有一个参考表,其中包含对这三列的描述。我需要在参考表中查找这三列,我的输出应为我提供三个新列,并提供相同的描述。

下面是查询。我担心的是,当我进行联接时,输出为Work_Type_Description提供了“空”和“实际描述”:代码中的这一行-“在t3上为“左联接[dbo]。[REF_table] t3]。[工作类型] = A.WORKTYPE“。而不是14行,我得到28行,并且sum函数显示为36,而不是1。有人可以帮助我解决此问题吗?我不知道可能是什么问题。

select  WORKORDERNO
       ,LOCATION
       ,WORKTYPE
       ,t3.[Work Type Description] as WORK_TYPE_DESCRIPTION
       ,WORK_SUBTYPE
       ,t2.[Sub Type Description] as SUB_TYPE_DESCRIPTION
       ,JOB_TYPE
       ,t.[Budget Process Description] AS PROCESS_NAME
       ,PROJECT_NUMBER
       ,SUM(ISNULL(CAST(COMPANYCOUNT AS INT),0)) AS COMPANY
       ,SUM(ISNULL(CAST(CONTRACTORCOUNT AS INT),0)) AS CONTRACTOR 

FROM
(SELECT WORKORDERNO
      ,STATUS
      ,cast(STATUSDATE AS DATE) AS ACT_FINISH
      ,WORKTYPE
      ,WORK_SUBTYPE
      ,LOCATION
      ,concat(WORKTYPE,WORK_SUBTYPE) as JOB_TYPE
      ,ASSIGNED_LABOR
      ,CASE WHEN [ASSIGNED_LABOR] IN ('X','Y','Z') THEN '1' ELSE '0'
                                      END AS COMPANYCOUNT
      ,CASE WHEN [ASSIGNED_LABOR] IN ('X','Y','Z') THEN '0' ELSE '1'
                                      END AS CONTRACTORCOUNT
      ,SUBSTRING(ACCOUNT, CHARINDEX('-', ACCOUNT, charindex('-', ACCOUNT, CHARINDEX('-', ACCOUNT, CHARINDEX('-', ACCOUNT,  
                CHARINDEX('-', ACCOUNT) +1 ) +1) +1) +1) +1, 13) AS PROJECT_NUMBER 
     ,FIELD_REMARKS
FROM [TTT].[dbo].[Current _Status] 
WHERE STATUS in ('COMP', 'FDCOMP', 'EBCOMP', 'EBERROR', 'FLN', 'FDCPERR')) A
left join [dbo].[REF_table] t on t.[Job Type] = A.JOB_TYPE
left join [dbo].[REF_table] t2 on t2.[Sub Type] = A.WORK_SUBTYPE 
left join [dbo].[REF_table] t3 on t3.[Work Type] = A.WORKTYPE 
where ACT_FINISH between '2018-04-30' and '2018-06-01' and LOCATION = 'ABC' AND WORKTYPE = 'C' 
and field_remarks is not null   
and t3.[Work Type Description] is not null
GROUP BY
      a.WONUM
     ,A.LOCATION
     ,a.WORKTYPE
     ,A.WORK_SUBTYPE
     ,A.JOB_TYPE
     ,t.[Budget Process Description]
     ,t2.[Sub Type Description]
     ,t3.[Work Type Description]
     ,PROJECT_NUMBER
   order by
        PROCESS_NAME

要删除重复项,我将此添加到where子句中,它解决了我的问题。 “并且t3。[工作类型描述]不为空”。我主要关心的是它提供的数量。

Ref表如下所示: enter image description here

我发现它显示了参考表中“ Worktype”行的数量。我过滤的工作类型类别在该列中的计数为36。我该如何解决这个问题?

请帮助。

1 个答案:

答案 0 :(得分:0)

很抱歉,回答这个问题的时间太长了,但我只是看到您使用REF_table的结构更新了问题。我认为这是您查询的相关部分:

select  
    [...]
   ,t3.[Work Type Description] as WORK_TYPE_DESCRIPTION
   ,t2.[Sub Type Description] as SUB_TYPE_DESCRIPTION
   ,t.[Budget Process Description] AS PROCESS_NAME
FROM
    (
        SELECT 
            [...]
            ,concat(WORKTYPE,WORK_SUBTYPE) as JOB_TYPE
            [...]
        FROM [TTT].[dbo].[Current _Status] 
        WHERE STATUS in ('COMP', 'FDCOMP', 'EBCOMP', 'EBERROR', 'FLN', 'FDCPERR')
    ) A
    left join [dbo].[REF_table] t on t.[Job Type] = A.JOB_TYPE
    left join [dbo].[REF_table] t2 on t2.[Sub Type] = A.WORK_SUBTYPE 
    left join [dbo].[REF_table] t3 on t3.[Work Type] = A.WORKTYPE 
    [...]

在子查询A中,您正在构造JOB_TYPE代码,该代码是WORKTYPEWORK_SUBTYPE代码的串联。但是随后您使用REF_tableJOB_TYPEWORK_SUBTYPE中的每一个作为谓词加入了WORKTYPE三次。如果所有三个值都彼此独立,并且您确定REF_table对于这些字段中任何一个的给定值最多包含一个记录,这可能很有意义。但是它们不是独立的:因为JOB_TYPEWORKTYPEWORK_SUBTYPE的函数,所以REF_table中具有特定JOB_TYPE代码的记录也将具有组成WORKTYPE的{​​{1}}和WORK_SUBTYPE上的信息。因此,您不需要对表进行三个联接;您只需要一个,就像这样:

JOB_TYPE

我认为JNevill可能仍然对select [...] ,t.[Work Type Description] as WORK_TYPE_DESCRIPTION -- References to t2 and t3 replaced with references to t ,t.[Sub Type Description] as SUB_TYPE_DESCRIPTION ,t.[Budget Process Description] AS PROCESS_NAME FROM ( SELECT [...] ,concat(WORKTYPE,WORK_SUBTYPE) as JOB_TYPE [...] FROM [TTT].[dbo].[Current _Status] WHERE STATUS in ('COMP', 'FDCOMP', 'EBCOMP', 'EBERROR', 'FLN', 'FDCPERR') ) A left join [dbo].[REF_table] t on t.[Job Type] = A.JOB_TYPE -- t2 and t3 joins removed [...] 的设计有所了解:似乎有些多余,因为如果您有一个REF_table可以与10个不同的WORKTYPE代码结合使用,则您当前的数据模型要求您存储WORK_SUBTYPE 10次不同的时间。如果该描述可以根据[Work Type Description]合法地变化,则现有结构有意义,但是如果单个WORK_SUBTYPE代码应该始终具有相同的描述,而不管哪个{{ 1}}与之配对,然后多次存储既浪费又容易出现数据完整性问题。 (换句话说,如果WORKTYPE最终在不同的记录上存储了相同的WORK_SUBTYPE代码的多个描述,您怎么知道哪个描述是正确的?)

您肯定有可能无法更改数据模型,或者由于某种原因而不想更改,这是完全可以理解的。在这种情况下,我只使用上面建议的查询更改。我只是认为这值得指出。