【发布时间】:2021-07-18 21:55:29
【问题描述】:
【问题讨论】:
【问题讨论】:
这样的事情应该会让你非常接近:
SELECT o.orderNumber
FROM orders o
LEFT JOIN customers c
ON c.customerNumber = o.customerNumber
WHERE c.customerName LIKE 'N%'
【讨论】:
这看起来像家庭作业,所以我要给你上一堂业务逻辑课,就好像它是家庭作业一样,因为很明显,这是一个简单的连接,如果你刚刚实现了 Neil 的解决方案,你可能不会考虑这些含义。
第一件事是:这需要回到业务上去“澄清”。
LIKE!这些都是重要的考虑因素。
如果您要将其放入企业的 SSRS 报告中,您会想知道您正在查看的确切字段,假设您将使用 customerName 字段,但企业可能决定使用任一 ContactNames,因为 customerName 可能包含类似:“Mr Norman Smith”或“Smith,Norman”或“Norman Smith”,混合了很多内容,因此在企业中拥有脏数据并不少见,特别是如果他们不重视数据-管理。您应该始终检查现场并咨询业务在进行之前。
SELECT DISTINCT customerName FROM customers
'N' 也不是固定字段,应该是用户可以输入的查询参数,因为,至少从我的行业经验来看,很清楚
em> 这最终将成为客户可以访问的报告。如果这将是放入 SSRS 报告中的数据,或者甚至推出,那么了解您的声明将会很有用。在 SSRS 报告中,您可以注释掉您的参数 SET 部分,甚至是您的 DECLARES(如果您需要有人评估您的代码,您永远不会删除它们),SSRS 报告生成器会提取这些参数,您可以在 Builder 中声明它们,并将文本值分配给标签的数字数据。
这是一个示例代码,如果企业给我的规范是 0 澄清且没有通信,我会为此编写。
/*Declares your variables*/
DECLARE @Initial varchar(1) --Declaring our Initial: Note this is why SQL is self documenting
DECLARE @FieldChoice = int --Declaring our field choice
SET @Initial = 'N' --Initial to search
SET @FieldChoice = 1 -- {1,2,3} = {customerName,contactFirstName,contactLastName}
/*Your query*/
SELECT O.orderNumber
FROM orders O
INNER JOIN customers C
ON C.customerNumber = O.customerNumber
WHERE (LEFT(C.customerName,1) IN (@Initial) AND @FieldChoice = 1)
OR (LEFT(C.contactFirstName,1) IN (@Initial) AND @FieldChoice = 2)
OR (LEFT(C.contactLastName,1) IN (@Initial) AND @FieldChoice = 3)
这还没有经过测试,因此您应该根据您的数据自行测试。
例如,在 SSRS 报告中:您将解析字段标题的数字,但为它们提供反映字段标题的 RichText 标签。这允许企业决定检查哪个标头。
如果您咨询企业并且他们说“实际上姓氏字段是我们想要的,我们不关心名字”,您最终会得到此代码。这就是为什么寻求澄清很重要。
/*Declares your variables*/
DECLARE @Initial varchar(1) --Declaring our Initial
SET @Initial = 'N' --Initial to search
/*Your query*/
SELECT O.orderNumber
FROM orders O
INNER JOIN customers C
ON C.customerNumber = O.customerNumber
AND (LEFT(C.contactLastName,1) IN (@Initial)
请注意,在这段代码中,我选择用“AND”代替“WHERE”,因为我利用 INNER JOIN 的过滤功能作为示例:但您应该始终检查您的 执行计划 因为这会影响您的查询时间。假设这是作业并且您正在学习。
如果这是家庭作业,您还应该考虑将其放入存储过程或函数中的可能性,具体取决于业务用例,但请记住,存储过程在推送时不喜欢 IN 子句出去报告。并不是它们不起作用,它们只是不能很好地处理值数组,因为存储的 proc' 参数只接受字符串。 https://mitchelsellers.com/blog/article/using-the-in-clause-with-stored-procedures
但要强调一个事实,即企业并不总是拥有干净的数据,而且从需求的角度来看问题并不明确,这是区分和通过之间的区别。
在撰写报告时,您必须考虑“企业试图实现的目标是什么”。
为什么不使用LIKE?嗯,它很好,在某些情况下表现更好,但如果你使用LIKE,你需要注意你的后端到前端的方法。如果您是从网页解析凭据,那么您只是将业务打开到 SQL 注入攻击,因为人们可以将内容解析为 LIKE,并且数据库将允许读取,所以再见客户数据。您刚刚通过使用 LIKE 子句删除了一层保护,因此剩下的保护您免受表格丢失的只是您的安全设置和参数框中字符的限制。如果您是数据设计师而不是网页上的开发人员,并且您没有意识到注入风险,那么这就是可能发生可怕错误的原因。
Neil T 给出的是一个完全可以接受的答案,它得到了通过,仅此而已。
【讨论】: