我正在尝试根据员工的工资(级别是薪级)更新员工表中的gradeid字段。
我需要参考的细节存在于不同的成绩表中。
我尝试用以下内容更新此内容,但不起作用:
UPDATE e
SET e.GradeID = g.gID
FROM Employee e
INNER JOIN Grade g
ON e.GradeID=g.gID
WHERE e.salary BETWEEN coalesce(g.minSalary, 0) AND coalesce(g.maxSalary, 9999999999)
我得到以下响应,但未更改任何字段:
(9 rows affected)
Completion time: ###
1条答案
按热度按时间tjjdgumg1#
您的查询无效,因为您已加入
Employee
以及Grade
已匹配键值。我非常谨慎地建议按照where子句中指定的条件加入这些表(非常小心,因为简单地将条件从where子句移动到from子句中join的a部分通常不是一件小事。在某些情况下,它可能会极大地影响意义和行为。但在这种情况下,这将是好的,因为它实际上是你的意图这样做。)
此外,我会避免
BETWEEN ... AND ...
表达和偏好分开比较(A >= 3 AND A <= 5
而不是A BETWEEN 3 AND 5
). 但这只是个人喜好。更重要的是,我当然会避免使用函数(比如
COALESCE
)在任何情况下,这样SQLServer都可以更好地使用索引(如果可用)。编辑:
关于索引的使用,gordon linoff在对我的回答的评论中指出
OR
查询条件中的运算符和函数一样具有破坏性。我在互联网上对此做了一个简短的研究,在cybertec的网站上找到了laurenz albe的文章“避免或提高查询性能”。然而,它是为postgresql编写的,但是我假设如果它不适用于sqlserver,那么它至少可以为专门针对sqlserver的调查提供一个起点。我将继续进一步查找特定于sql server的信息。
作为查询结构的一个可能的例子
OR
回到函数替代,我将我的第一个查询重写为:为了演示的目的,我只包含了这个替代查询。我没有分析性能,因为我没有匹配的填充数据库。因此,我会留下任何期望的测量或查询计划调查,由你决定。结果也可能是,四个独立的更新查询可能同样好(而且内存占用更少)。
提示:
请注意,读取代码的频率要比编写代码的频率高。因此,始终创建可读和可维护的代码非常重要。这对于sql来说尤其如此,它通常被认为很难阅读和理解,即使它的格式很好。任何优化都应该被完整地记录下来。在创建查询时,请始终创建尽可能简单明了的第一个版本。优化之后,您可以在查询的文档/注解中包含该简单的原始查询,这将在将来的代码分析、维护和/或优化任务中简化对查询的理解。