更新数据库记录中单个字段时的最佳实践

过早的优化是万恶之源。

有理由这样做吗,你真的有带宽问题吗?

根据我的经验,跟踪变更可能需要很多工作(即需要维护很多代码),这取决于它是如何实现的。有一些优雅的方式,但我认为你做的很好,除非有证据支持改变。

如果您计划实现某种定制的变更跟踪形式,我肯定不会与数据库“聊天”。当您第一次从数据库中提取对象时,在本地复制它,并与之进行比较。

也许除了带宽之外,您还需要考虑多用户争用。根据应用程序的设计方式,更新所有字段方法可能会导致问题。

如果有两个用户同时加载记录编号1。用户A将姓氏从“smith”更改为“smythe”,然后保存。然后用户B将地址1从“The Street”更改为“Any Street”,并保存。

在您的方法下,第二次保存还将把姓氏重新恢复为“smith”(因为这就是用户b加载它时的情况)。

在这之后,您还需要在保存时进行其他检查(可能是某种时间戳),以确保数据库中的值是您认为的值。

假设您在Web服务器和数据库服务器之间有千兆网络连接,那么您必须在100兆数据区域中更新somwhere 每秒 甚至接近成为一个问题。每天大约8兆字节。我猜你没有更新这么多的数据,所以这可能不是问题。

网络带宽在所有级别上都在不断提高。除非你在某个地方遇到了瓶颈,不要担心。即便如此,我的预感是,与在其他地方发现性能改进相比,获得的收益足够小,以至于您将花费更多的时间和精力(以及风险)来优化您的更新。

好吧,您要么按照您所做的方式来做(每次都有效,并通过每个字段),要么花时间为每个字段生成定制的SQL,然后为每个字段传递一条SQL语句,或者在运行中生成大量只包含更新字段的SQL(如果您犯了错误,则存在注入SQL的风险)。通过在参数化存储过程中进行更新,并且只在字段值之间传递,而不是在名称之间传递,您可能会获得更好的带宽节约。

除非带宽真的是个问题,否则我认为你没有问题。无论如何,SP路由是更好的选择。

其中一个字段不是表的pk吗?你真的在更新pk吗?外国钥匙呢?你也在更新吗?

问题不在于带宽。至少隔离记录的非关系元素,并且只更新该集合(不包括pk和外键)。

我发现自己也处于同样的境地。我编写了自己的轻量级ORM/DAL,以接口到一个非优化设计的数据库,即具有200多个字段的表。

我发现确实有一个开销与试图更新一行的所有字段相关,而不仅仅是那些已更改的字段。

在我的例子中,我可以通过使用ORM属性的智能“setters”来解决这个问题,如果试图修改某个特定字段,ORM属性将记录这些属性。这意味着当我将对象提交回数据库时,我可以发出一条SQL更新语句,该语句只引用那些标记为已修改的字段。

N.B. 对于select语句,最佳实践要求显式引用要返回的字段,而不是使用“select*from”。有人说这是因为性能/带宽的原因,所以反向更新是有意义的。