跳到底部以避免冗长的解释
好的,所以。
我正在公司内部网上工作以管理客户工作。工作由元素组成:示例元素可能是“构建六页网站”或“设计徽标”。
每个元素都包含一系列角色时间,因此“构建一个六页网站”可能包括四个小时的“开发人员”费率和两个小时的“设计师”费率(好的,可能更长一点): / p>
显然,不同的客户获得不同的小时费率。而且,尽管已经在系统中考虑到了这一点,但它并没有给我们足够的灵活性。传统上,我们的客户经理非常......特别......他们的定价:“构建一个六页网站”元素可能包括客户“Bob”的标准四小时开发人员,但客户“八小时”哈里”。
忍受我。我很快就会得到实际的代码。
元素当然存储在“Elements”数据库表中 - 该表只包含一个ID和一个文本标签。
我正在进行的“我们需要特定于客户端的元素”问题的解决方案是在此表中添加“客户端”字段。然后,我们可以浏览并添加任何特定于客户端的可用元素版本,并根据需要进行调整。
当客户经理去为他们的工作添加元素时,他们应该只看到(a)任何人都可以使用的元素 - 也就是说,他们有一个NULL客户端字段,或者(b)特定于作业客户端。
到目前为止,SELECT WHERE。
但这不会削减它。如果我专门为Harry添加第二个“构建六页网站”元素,那么为Harry工作添加元素的客户经理将看到标准版本和Harry的元素版本。这不好。如果没有适用的客户端特定版本,他们应该只看到标准版本。
好的...... soooo:以及在元素表中添加“client”字段,添加“父元素”字段。然后我们可以做一些神奇的自我引用,包括将表连接到自身,并仅获取相关角色。
我期待已久的问题是:
哦,看,实际问题
id label client parent_element
1 Standard Thing NULL NULL
2 Harrys Thing 1 1
3 Bobs Thing 2 1
4 Different Thing NULL NULL
鉴于此表结构,我如何编写一个接受“客户端ID”参数并返回的SQL查询:
对于额外的奖励积分,结果应包括父元素标签。因此,对于客户端ID 1,例如:
id label standardised_label client parent_element
2 Harrys Thing Standard Thing 1 1
4 Different Thing Different Thing NULL NULL
答案 0 :(得分:3)
SELECT mm.*, md.label AS standardized_label
FROM mytable md
LEFT JOIN
mytable mc
ON mc.parent_element = md.id
AND mc.client = @client
JOIN mytable mm
ON mm.id = COALESCE(mc.id, md.id)
WHERE md.client IS NULL
在(client, parent_element)
上创建一个索引,以便快速工作。
请参阅SQLFiddle。