Вы когда-нибудь сталкивались с ужасными историями о SQL Server? Знаете, те ситуации, когда вы натыкаетесь на код, который заставляет вас смеяться, плакать и сомневаться в рассудке разработчиков, которые его создали? Мы все были там.

В этом блоге мы рассмотрим некоторые распространенные ошибки в SQL Server и обсудим, как их избежать. Погрузимся в это!

Кошмар с триггерами

Представьте триггер, который вызывает хранимую процедуру, которая, в свою очередь, вызывает другую хранимую процедуру на другом сервере с использованием связанного сервера. И, чтобы сделать все еще хуже, у этой второй хранимой процедуры есть свой собственный триггер, который вызывает еще одну хранимую процедуру с использованием связанного сервера. Это похоже на бесконечный цикл сложности.

Такой запутанный дизайн не только делает устранение неполадок настоящим кошмаром, но и вводит ненужные накладные расходы на производительность. Очень важно тщательно анализировать зависимости и потенциальные узкие места при проектировании триггеров и хранимых процедур.

Урок, извлеченный из этого: Держите свой код чистым и избегайте избыточных слоев триггеров и хранимых процедур. Упростите свою логику и минимизируйте использование связанных серверов, когда это возможно.

Перебор с NOLOCK

NOLOCK, также известный как READ UNCOMMITTED, является подсказкой запроса, которая позволяет читать неподтвержденные данные. Хотя он может быть полезен в определенных сценариях, его следует использовать с осторожностью и оглядкой.

Представьте систему, в которой каждая хранимая процедура начинается с оператора “SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED”, и каждая ссылка на таблицу сопровождается подсказкой NOLOCK. Такой подход не только влияет на сеанс, но и вводит ненужные риски.

Использование NOLOCK для каждой ссылки на таблицу может привести к несогласованным и потенциально неправильным результатам. Важно понимать последствия разных уровней изоляции и выбирать подходящий в зависимости от конкретных требований ваших запросов.

Урок, извлеченный из этого: Избегайте использования NOLOCK в качестве кнопки “ускорения”. Вместо этого тщательно рассмотрите уровень изоляции, необходимый для каждого запроса, и используйте NOLOCK с осторожностью, если вообще используете.

Вывод

Разработка SQL Server может быть сложной, и ошибки неизбежны. Однако, изучая распространенные проблемы и следуя bewt практикам, мы можем избежать ненужной сложности и улучшить производительность и поддерживаемость нашего кода.

Помните, что простота и ясность должны быть руководящими принципами при проектировании решений на SQL Server. Держите свой код чистым, минимизируйте зависимости и выбирайте подходящий уровень изоляции для ваших запросов.

Следите за нашими будущими блог-постами, где мы будем делиться еще больше советов и трюков по SQL Server!