Уровни изоляции транзакций (MS SQL)

Часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.

Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.

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

Что нам стоит Cache построить?

Написано не мало хороших статей на тему «Что, как и где кешировать». Так почему же ещё раз мусолить эту тему? А потому что тема достаточно важная, а многие, пока не столкнуться с конкретными проблемами, не считают нужным с ней разбираться. Так что аудитория, на которую я рассчитываю, это те, кто к моменту выхода уже существующих статей были в них не заинтересованы, но сейчас интерес есть, и они не пройдут мимо.

Я постараюсь кратко осветить основные моменты организации кеширования, после чего рассмотрю новшества .Net Framework 4.0, которые должны упростить жизнь разработчиков (речь пойдёт о In-memory кеше вне ASP.NET инфраструктуры).

Azure Cache

Сегодня сложно представить какую-либо высоконагруженную систему, в которой можно было бы обойтись без кеширования данных. Поэтому практически всегда используются те или иные механизмы кеширования. В контексте облачных решений это даёт следующие преимущества:

• увеличение скорости чтения/записи данных, что позволяет уменьшить время отклика системы;
• обеспечения «общей памяти» для различных экземпляров, что является одним из необходимых условий горизонтального масштабирования
• снижение стоимости, за счёт более редкого обращения к базе данных (чтение из БД является более дорогой операцией, по сравнению со чтением значения из кеша)

На сегодняшний день, для разработчиков платформы Azure доступно несколько моделей организации кеширования:

• Кеш в роли (In-Role Cache)
• Управляемая служба кеша (Managed Cache Service)
• Кеш Azure Redis (Azure Redis Cache)

Microsoft SQL Server Data Tools

В данной статье хотел бы рассказать про набор полезных дополнений к Visual Studio, которые могут в значительной мере облегчить разработку баз данных на основе MS SQL Server.

Основными преимуществами использования SSDT я бы выделил следующее:

• возможность простого изменения (refactoring) схемы базы (можно переименовать колонку таблицы и все Views, Functions и Stored Procedures ссылающиеся на неё автоматически будут исправлены для отражения изменений)
• создание юнит тестов для базы данных
• хранение структуры базы данных в Source Control
• сравнение схемы/данных c возможностью генерации скрипта для приведения схемы/данных к требуемому состоянию

Безусловно на этом плюсы использования SSDT не заканчиваются, но остальное не так сильно впечатляет, как то, что упомянуто выше. Если вас интересует, как воспользоваться этими и другими преимуществами — прошу под кат.

Не пора ли написать код, который будет писать код (CodeDOM)

Думаю мало кто удивится, узнав, что существует множество способов авто-генерации кода. Это code-behind файлы, которые любезно создаёт Visual Studio, это T4 шаблоны, которые позволяют упростить генерацию однотипных файлов. Так же есть ряд способов на этапе исполнения программы динамически определить логику работы (System.Reflection.Emit namespace или Expression Trees). Но сегодня я хотел бы рассказать о другом подходе – CodeDOM.

В данной статье я покажу 2 примера:

1. Как динамически создать программу “Hello World”. В результате у нас будет *.cs файл и скомпилированная программа, которую мы запустим.
2. На базе уже имеющегося кода из примера 1 мы увидим как просто сделать генерацию DTO классов на основе схемы имеющейся базы данных.

Struct:Interface = Boxing?

interface IMyInterface { }
struct MyStruct : IMyInterface { }

class MyClass
{
    public void Method(IMyInterface value){ }
}

Вопрос №1: Будет упаковка структуры при передачи в метод Method()?

Вопрос №2: Как избежать упаковки?

Struct vs Class

На собеседованиях я не раз задавал вопрос: «В каких случаях вы предпочтёте использование структуру вместо класса?». 90% людей, почему-то думают, что их спрашивают о различиях структур и классов. И поэтому начинают рассказывать о том где хранятся значимые и ссылочные типы, о невозможность наследования структур и т. п. Хотя они говорят всё верно, но это не совсем то, что их спрашивают. В этой заметке я попытаюсь ответить на поставленный вопрос.