根据连接表中的计数从一张表中排除记录
我有两个表:优惠券和响应。
优惠券表包括以下字段:
- VendorID [key]
- CouponID [key]
- CouponDescription
响应表包括以下字段:
- RespondentID [key]
- CouponID [key]
- (供应商 ID 在此表中未重复。)
- 已接受 [true/false]
- 已拒绝 [ true/false]
- 评级 [1 到 5]
当某人接受优惠券时,他们最终会在“响应”表中对其进行评级。同样,当有人拒绝优惠券时,拒绝会出现在“响应”表中。
从优惠券表中获取可用优惠券列表时,我想排除之前收到受访者两次或多次拒绝的供应商。例如,如果 RespondentID 3 之前拒绝了来自供应商 47 的两张或更多优惠券,则来自供应商 47 的所有优惠券将不再显示给 RespondentID 3。
有两件事让像我这样的 SQL 新手感到困难。
第一个是如何编写子查询来计算来自特定供应商和特定受访者的拒绝。。
第二个是如何将 Responses 表连接回(可以这么说)到 Coupons 表,以便 Responses 表的子查询将其结果基于 RespondentID(位于 Responses 表中)和 VendorID (这不在响应表中,必须根据 CouponID(在两个表中)确定。
非常感谢您的帮助。
I have two tables: Coupons and Responses.
The Coupons table includes fields such as:
- VendorID [key]
- CouponID [key]
- CouponDescription
The Responses table includes fields such as:
- RespondentID [key]
- CouponID [key]
- (VendorID not repeated in this table.)
- Accepted [true/false]
- Rejected [true/false]
- Rating [1 to 5]
When someone accepts a coupon, they eventually rate it in the Responses table. Likewise, when someone rejects a coupon, the rejection appears in the Responses table.
When fetching a list of available coupons from the Coupons table, I'd like to exclude vendors who previously received two or more rejections from a respondent. For instance if RespondentID 3 previously rejected two or more coupons from Vendor 47, all coupons from Vendor 47 would no longer be shown to RespondentID 3.
Two things make it difficult for a SQL novice like myself.
The first is how to write the subquery that counts rejections from a particular vendor and by a particular respondent.
The second is how to join-back (so to speak) the Responses table to the Coupons table so that the sub-query of the Responses table bases its result on the RespondentID (which is in the Responses table) and the VendorID (which is not in the Responses table and must be determined based on the CouponID (which is in both tables).
Thanks for your assistance. It's always appreciated.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
可能是这样的:
我从未使用过
HAVING
而不将其值包含在SELECT
中,但我认为它可以工作。另外,不确定 Rejected 的数据类型,可能 SUM() 不起作用。Could be something like this:
I've never used
HAVING
without including the value it in theSELECT
but I think it could work. Also, not sure about the data type of Rejected, probably SUM() won't work.好的,这是一个长期的尝试,我不确定这个查询是否会实际运行,但我认为关键是您必须包含优惠券表两次。试试这个(但是我认为
where
是不允许的):OK, this is a long shot and I'm not sure this query will actually run, but I think the key is that you have to include the Coupon table twice. Try this (I think, however, that
where
is not allowed like this):这是我想出的...
它的缺点是需要额外嵌入 SELECT,但似乎大多数性能损失都是在我尝试从 Coupons 表中排除特定 OriginatorID 时发生的。例如,手动输入排除项,例如...
具有相同的效果。在 50 行的测试表上,处理时间为 0.27 秒,而无约束查询的处理时间为 0.08 秒。
额外的嵌入是因为我需要一个单独的列来表示外部 NOT IN(即我要排除的 OriginatorID)。这意味着我必须首先创建 SUM,然后隔离 SUM 小于条件 (1) 的记录,然后排除这些记录。
Here's what I came up with...
It has the disadvantage of an additional embedded SELECT, but it appears that most of the performance hit occurs the moment I attempt to exclude particular OriginatorIDs from the Coupons table anyhow. For example, manually entering an exclusion, such as...
has the same effect. On a test table of 50 rows, the processing time is .27s as opposed to an unconstrained query that has a processing time of .08s.
The extra embedding is due to my needing a single column for the outer NOT IN (i.e., the OriginatorID's that I'm seeking to exclude). That meant I had to first create the SUMs, then isolate the records whose SUM was less than the criterion (1), and then exclude those records.