编写 SQL 查询以显示客户名称以字母“N”开头的所有订单号

问题描述

给定图片，我想找到名称以“N”开头的所有客户详细信息的订单号。

解决方法

这样的事情应该会让你非常接近：

SELECT o.orderNumber
FROM orders o
LEFT JOIN customers c
ON c.customerNumber = o.customerNumber
WHERE c.customerName LIKE 'N%'

,

这看起来像作业，所以我要给你上一堂业务逻辑课，就好像它是作业一样，因为很明显，这是一个简单的连接，如果你刚刚实施了尼尔的解决方案，你可能不会考虑这些含义。

第一件事是：这需要回到业务部门进行“澄清”。

• 代码的用途是什么？ （报告，只是一次过 [很少是一次过]，感觉检查）
• customerName 字段有多干净？
• 名字还是姓氏？
• 如果您能帮上忙，请不要使用LIKE！

这些是重要的考虑因素。

如果您要将其放入企业的 SSRS 报告中，您会想知道您正在查找的确切字段，假设您将使用 customerName 字段，但企业可能决定使用 ContactNames 中的任何一个，由于 customerName 可能包含诸如“Mr Norman Smith”或“Smith,Norman”或“Norman Smith”之类的内容，因此在企业中拥有脏数据的情况并不少见，尤其是如果他们不重视数据的价值- 管理。您应该始终在之前检查现场并咨询业务。

SELECT DISTINCT customerName FROM customers

“N”也不是固定字段，而是用户可以输入的查询中的参数，因为至少根据我的行业经验很清楚 em> 这将最终成为客户可以访问的报告。

如果这将是放入 SSRS 报告中的数据，甚至被推出，了解您的声明将非常有用。在 SSRS 报告中，您可以注释掉您的参数 SET 部分，甚至您的 DECLARES，（如果您需要有人评估您的代码，您永远不会删除它们）并且 SSRS 报告生成器会将这些参数取出，您可以在构建器中声明它们，并为标签的数字数据分配文本值。

这是我会为此编写的示例代码，如果一家公司给了我 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

但要强调的是，企业并不总是拥有干净的数据，而且从需求的角度来看问题并不明确，这就是 Distinction 和 Pass 之间的区别。

在撰写报告时，您必须考虑“企业试图实现的目标是什么”。

为什么不使用 LIKE？嗯，它很好，在某些情况下性能更好，但如果您确实使用 LIKE，则需要了解后端到前端的方法。如果您从网页解析凭据，您只是让您的业务面临 SQL 注入攻击，因为人们可以将内容解析为 LIKE 并且数据库将允许读取，所以再见客户数据。您刚刚使用 LIKE 子句移除了一层保护，因此剩下的保护您免受表删除的只是您的安全设置和对参数框中字符的限制。如果您是网页上的数据设计者而非开发者，并且您不知道注入风险，那么就会发生可怕的错误。

Neil T 给出的答案是一个完全可以接受的答案，它通过，仅此而已。