我们的工作涉及更新产品，我们有一个很大的产品表，价格和其他相关信息每小时更新一次。假设它是一家亚马逊商店，我们正在谈论亚马逊产品，我们必须更新销售价格，buy box 价格等。我们每小时从亚马逊提取信息到我们的程序中并更新数据库中的数据。
我的工作流程是，将数据库中的所有产品拉入程序中（我们使用 C# 和 EF Core），更新相关产品，并将更新发送回数据库。
这种方式的代价是从数据库中读取很多信息到程序中，但是我觉得这样很高效，因为 EF Core 有变化检测，所以即使我为所有产品分配了进货产品的价格，如果有is no change EF核心不会改变任何东西，它只会为那些信息发生变化的产品生成更新语句。
此外，它不会生成大的更新语句，它会生成小的、有针对性的更新语句，例如
update products, set BuyBoxPrice = 12.23 where productid = 23345.
我正在和一个非常有天赋的开发人员一起工作，他对 SQL 非常自然，他认为这种方式是错误的，我宁愿将所有传入的信息放在一个名为 #products 的临时表中，并将其发送到数据库中，然后运行一个应该这样做的存储过程，
update products, set BuyBoxPrice = #products.buyboxprice from products inner join #products on products.produtid = #products.productid.
因此，这种方法避免了从数据库中进行大量读取。
我不是那么有经验，我的问题是，读取会创建锁或降低数据库性能，可能是吗？
下面是我对他的方法不满意的原因。
它创建了很多不必要的更新，这在我看来是非常浪费的，因为只有 25% 的信息发生了变化，所以为什么要更新所有列。
我的同事反驳说，我可以通过添加 where 语句来解决这个问题，比如
update products where products.buyboxprice <> #products.buyboxprice
我不认为这会减少你支付的罚款，我认为它仍然是相同的效果。
另一个主要担心是大型更新会创建锁，仅此一项就应该避免。现在我当然可以将更新分解成小于 3000 的块等。
第三点，当SQL肚子疼的时候，它会全身而退，然后开始发生奇怪的事情，客户大喊大叫老板生气，我对发生的事情几乎没有了解，但是在C#中，只要有什么崩溃就对了对我来说很清楚。
所以我的问题是，谁是对的，是通过读取和 EF 核心还是通过 SQL 进行更新的性能更高