Плохо ли использовать хранимые процедуры CRUD для представления с NOLOCK?

Question

Наши администраторы баз данных создали шаблон, в котором уровень нашей базы данных подвергается воздействию EF через представления и хранимые процедуры CRUD.CRUD работает против зрения.Все виды имеют подсказку NOLOCK.Насколько я понимаю, NOLOCK - это грязное чтение, и это заставляет меня нервничать.Наши базы данных невелики по объему, но кажется, что общий NOLOCK не очень масштабируем при сохранении целостности данных.Я понимаю, что разделение - это хорошая идея, но проблема в том, что мы этого не делаем.Наши внешние объекты выглядят так же, как наши виды, которые отображаются с 1 на 1 с нашими таблицами.

«Если мы хотим изменить базовую модель данных, мы можем».... но мы неЯ не буду касаться того, что это за PITA с точки зрения инструментов VS / EF.

Плохо ли использовать NOLOCK в этой ситуации?Поскольку наша база данных выглядит точно так же, как наша библиотека классов, я думаю, что имеет смысл просто избавиться от всего слоя view / sproc и поразить БД непосредственно из EF, не так ли?

Answer 1

Блог Боба Бошемина содержит много хороших статей об оценке сильных и слабых сторон обертки ORM от опытного дизайнера БД. Хорошо проверить, что wtf действительно происходит, когда вы используете EF. Что касается использования подсказки NOLOCK, это будет хорошо, пока это не так! Как вы, кажется, уже знаете, когда вы масштабируете в определенной степени, вы столкнетесь с любыми проблемами целостности, но это зависит от того, насколько вы терпимы к фантомному чтению, записи и т. Д. это скорее плохая идея.

Answer 2

Выдача nolock - абсолютно грязное чтение.Временами это никак не влияет, но в некоторых сценариях у вас могут быть наборы результатов с отсутствующими записями или дубликатами Ицик Бен-Ган имеет некоторые вопросы и ответы по этой теме.Причина использования хранимых процедур для абстрагирования ваших операций CRUD довольно очевидна, когда вы хотите провести некоторую оптимизацию хранилища после перехода проекта в режим обслуживания.Думайте о взглядах как о способе не беспокоиться об этом позже.Для ваших администраторов баз данных может быть проще оптимизировать код доступа к данным, не тратя время на разработку.Я не могу сказать, что ваши DBA правы или нет, основываясь только на данных этого поста.Просто слишком много переменных, которые могут повлиять на решение.Полная реализация nolock как правильной опции была бы редкостью.НТН