我们的 DBA 创建了一种模式，其中我们的数据库层通过 View 和 CRUD 存储过程暴露给 EF。 CRUD 与 View 背道而驰。所有 View 都有 NOLOCK 提示。据我所知，NOLOCK 是脏读，这让我很紧张。我们的数据库容量不大，但似乎一揽子 NOLOCK 在保持数据完整性的同时不是很可扩展。我知道解耦是个好主意，但问题是我们没有。我们暴露在外部的对象看起来就像我们的 View 一样，它们与我们的表 1 到 1 映射。
“如果我们想改变底层数据模型，我们可以。” ......但我们没有。从 VS/EF 工具的角度来看，我不会触及这一切是什么 PITA。
这种情况下用NOLOCK是不是不好？由于我们的数据库看起来与我们的类库完全一样，我认为摆脱整个 View /sproc 层并直接从 EF 访问 DB 是有意义的，是吗？
最佳答案
发出 nolock 绝对是脏读。有时这不会产生任何影响，但在某些情况下，您可能会得到缺少记录或重复的结果集 Itzik Ben-Gan 有一些关于此主题的问答。当您想在项目进入维护模式后进行一些存储优化时，使用存储过程来抽象您的 CRUD 操作的原因非常明显。将 View 视为您以后无需担心的一种方式。您的 DBA 也可以更轻松地优化数据访问代码，而无需花费您作为开发人员的时间。我不能仅根据这篇文章中的数据就说您的 DBA 是对还是错。可能会影响决策的变量太多了。但是，作为正确选项的 nolock 的全面实现很少见。 HTH