使用带NOLOCK视图的CRUD存储过程是否不好？

Question

使用带NOLOCK视图的CRUD存储过程是否不好？

4

我们的数据库管理员创建了一种模式，将我们的数据库层通过视图和CRUD存储过程暴露给EF。 CRUD针对视图进行操作。所有视图都带有NOLOCK提示。据我所知，NOLOCK是脏读取，这让我很紧张。虽然我们的数据库不是高容量的，但似乎全局使用NOLOCK在保持数据完整性方面并不太可扩展。我知道解耦是一个好主意，但问题在于我们不知道。我们外部公开的对象看起来就像我们的视图，这些视图与我们的表一一映射。

“如果我们想要更改基础数据模型，我们可以。”…但我们没有。我不会触及从VS / EF工具角度来看这一切有多麻烦的问题。

在这种情况下使用NOLOCK是否不好？由于我们的数据库看起来与我们的类库完全相同，因此我认为直接从EF访问数据库并摒弃整个视图/存储过程层是有道理的，不是吗？

- TheHurt

我不是 DBA，但我们只在需要进行大规模数据填充过程并且需要监控并打印填充状态时才使用 NOLOCK。 - Martin Ongtangco

1

这个问题的答案可能需要一篇论文来回答。简单来说，这取决于情况。通过 EF，你可以获得很多好处，但也可能失去很多。在我的一些项目中，我会使用 LINQ to SQL/EF，而在其他项目中，我会创建存储过程。这完全取决于我要拉取的数据量、我试图实现的优化以及我需要数据返回/更新的速度的严重程度。有时候，我想尽可能地减少我和数据库之间的所有麻烦，只想要原始数据。而其他时候，我想要 EF 提供的序列化功能来处理我的数据。 - George Johnston

1

这可能在http://dba.stackexchange.com/上表现得更好。 - IAbstract

2个回答

1

bob beauchemin blog有许多关于ORM包装器的优缺点的好文章，从专业的数据库设计师角度来衡量。学习使用EF时，很值得一看。关于使用NOLOCK提示，这是好的，直到它不是为止！当你扩展到一定程度时，你会遇到各种完整性问题，但这取决于你对幻读、写入等容忍度。基本上，你想要更精确的原子性，这就越不好的想法。

- bumble_bee_tuna

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- doug_w · Accepted Answer

发出nolock绝对是一种肮脏的读取方式。有时候这没有影响，但在某些情况下，您可能会得到缺少记录或重复记录的结果集Itzik Ben-Gan关于此主题有一些问答。使用存储过程来抽象您的CRUD操作的原因在项目进入维护模式后进行一些存储优化时非常明显。将视图视为一种让您不必担心以后的方法。这也可以更轻松地让您的DBA优化数据访问代码，而不会消耗您作为开发人员的时间。我不能仅根据本帖中的数据说您的DBA是对还是错。决策可能涉及太多变量。然而，nolock的全面实施是正确选项的情况很少见。希望能对您有所帮助。