我们的DBA创建了一种模式,我们的数据库层通过视图和CRUD存储过程向EF公开. CRUD对视图起作用.所有观点都有NOLOCK提示.根据我的理解,NOLOCK是一个肮脏的阅读,这让我很紧张.我们的数据库数量不高,但似乎毯子NOLOCK在保持数据完整性的同时不具备高度可扩展性.我认为脱钩是一个好主意,但问题是我们没有.我们外部暴露的对象看起来就像我们的视图,它们与我们的表一起映射1到1.

“如果我们想要改变基础数据模型,我们就可以.” ……但我们没有.从VS / EF工具的角度来看,我不会谈到PITA的全部内容.

NOLOCK在这种情况下使用不好吗？由于我们的数据库看起来与我们的类库完全相同,我认为只需摆脱整个视图/ sproc层并从EF直接命中数据库就可以了,是吗？

最佳答案 发布一个nolock绝对是一个肮脏的阅读.有时候这没有影响,但在某些情况下,您可能会有缺少记录或重复的结果集
Itzik Ben-Gan有关于此主题的一些问答.当您希望在项目进入维护模式后进行一些存储优化时,使用存储过程来抽象CRUD操作的原因非常明显.将这些观点视为一种让您以后无需担心的方式.您的DBA可以更轻松地优化数据访问代码,而不会浪费您作为开发人员的时间.我不能仅根据这篇文章中的数据说你的DBA是对还是错.决策中可能存在太多变量.尽管如此,将nolock作为正确选项的全面实施将是罕见的. HTH