Первый взгляд на LocalDB

Обновлено 22 марта 2012.

С обновлением .NET 4.0.2 добавилась возможность использовать LocalDB в качестве хранилища данных. Давайте посмотрим зачем нужен и как использовать этот новый вариант SQL Server.

Обзор LocalDB

Первым вопросом, человека услышавшего про LocalDB, наверное будет "а зачем нужен?" И правда, ведь в линейке продуктов Microsoft уже есть SQL Server, SQL Server Express и SQL Server Compact.

LocalDB это вариант SQL сервера, доступный в рамках SQL Server 2012 Express. Давайте сравним различные редакции (все три доступны для бесплатного использования):

Express 2012 LocalDB Compact 4.0
Тип сервис отдельный процесс (sqlservr.exe), запускаемый приложением in-process DLL
Поддержка 64-bit Да Да Да
Максимальный размер базы данных 10 GB 10 GB 4 GB
Поддержка FileStream Да Нет Нет
Поддерживаемые возможности широкий набор возможностей, включая хранимые процедуры, такие типы данных как Geometry и Geography и т.д. широкий набор возможностей, включая хранимые процедуры, такие типы данных как Geometry и Geography и т.д. ограниченный набор поддерживаемых возможностей
Transact-SQL Да Да Да
Procedural T-SQL Да Да Нет
Simple transactions Да Да Да
Distributed transactions Да Да Нет
Native XML, XQuery/XPath Да Да Нет
Role-based security Да Да Нет
Stored procedures, views, triggers Да Да Нет
Число одновременных соединений Нет ограничения Нет ограничения, но только локальные подключения 256

Таким образом, LocalDB это альтернатива Express версии, которая не является постоянно запущенным сервисом и позволяет только локальные подключения. При этом, в отличии от Compact, она поддерживает весь функционал Express, за исключением FileStream.

Установка LocalDB

На данный момент LocalDB доступна как часть SQL Server 2012 Express. Поэтому достаточно скачать и установить Microsoft SQL Server 2012 Express RTM. При этом, если нет необходимости в установке SQL Express как сервиса, то можно убрать отметку с опции Database Engine или перевести его в режим ручного запуска. Для управления LocalDB можно будет использовать SQL Server Managment Studio (SSMS).

Обратите внимание, что Visual Studio 2012 Beta уже содержит в своей поставке LocalDB RC0. Поэтому после её установки необходимо удалить данную предварительную версию и поставить финальную.

Кроме того, для работы с Visual Studio 2010 потребуется обновить .NET Framework до версии 4.0.2. Для этого необходимо установить Service Pack 1 (SP1), а также Design-time Update (KB2544525).

Использование LocalDB в приложении

Попробуем LocalDB в действии. Давайте создадим простой пустой (empty) ASP.NET MVC 3 проект. Назовем его LocalDBTest. Создадим специальную папку для хранения данных – AppData. Также обязательно необходимо в свойствах проекта установить .NET 4.0.2 в качестве Target Framework (по умолчанию используется 4.0).

В папку Models добавим класс UserProfile, содержащий следующую Модель (файл UserProfile.cs):

namespace LocalDBTest.Models
{
    using System.ComponentModel.DataAnnotations;

    public class UserProfile
    {
        public int Id { get; set; }

        [Required]
        public string FirstName { get; set; }

        public string LastName { get; set; }

        [DataType(DataType.MultilineText)]
        public string Description { get; set; }
    }
}

Соберем проект. Затем, c помощью заготовок, создадим Контроллер HomeController, с поддержкой стандартных операций с помощью Entity Framework, и Представления для них.

Тестовое приложение почти готово. Остается только указать, что необходимо использовать LocalDB. Все отличие от проекта, использующего другие варианты SQL Server, будет заключаться в строке соединения.

<connectionStrings>
  <add name="LocalDBTestContext"
       connectionString="Server=(localdb)\v11.0;Database=LDBTest;Integrated Security=true;"
       providerName="System.Data.SqlClient"/>
</connectionStrings>

Как хорошо видно, вместо (local) для Express версии, используется (localdb)\v11.0. Дело в том, что .NET 4.0.2 добавляет поддержку LocalDB в стандартный SqlClient.

По умолчанию файлы баз данных размещаются в папке "C:\Users\[UserName]". Однако, LocalDB позволяет переопределить это место для каждого приложения. Для этого в строке соединения необходимо задать параметр AttachDbFileName:

<connectionStrings>
  <add name="LocalDBTestContext"
       connectionString="Server=(localdb)\v11.0;Database=LDBTest;Integrated Security=true;AttachDbFileName=|DataDirectory|\LDBTest.mdf"
       providerName="System.Data.SqlClient"/>
</connectionStrings>

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

Итак, для использования LocalDB вместо других редакций SQL Server достаточно указать соответствующую строку подключения в файле конфигурации проекта.

В завершении стоит отметить, что для администрирования созданных таблиц можно использовать SQL Server Management Studio, входящую в поставку Microsoft SQL Server 2012. При этом в качестве адреса сервера необходимо также указать строку "(localdb)\v11.0". Кроме того, как уже упоминалось, Visual Studio 2012 также содержит встроенный инструмент c аналогичной функциональностью.


Исходный код проекта (C#, Visual Studio 2010): LocalDBTest.zip

Комментарии (16) -

Павел 08.11.2011 18:00:09

так и всё-таки, "а зачем нужен?" Smile

Ведь если приложению нужна база, то оно создаст отдельный процесс и он также будет постоянно висеть пока приложение работает, а если в приложении иногда требуется работать с базой, то не будет ли проблемой каждый раз запускать и останавливать отдельный процесс?

Ну и вопрос остается по поводу производительности, насколько я понимаю она не должна быть хуже, чем у MS SQL Express?

@ Павел: Сервис (Express) висит постоянно (ручное управление сервисом на end-user компьютере это маловероятно). А LocalDB - только если есть использующее его приложение. Кстати, поскольку LocalDB это не сервис, то каждое приложение будет порождать свой child-процесс.

Кроме того, требуется меньше настроек. Например, LocalDB изначально и принципиально ограничен только локальными подключениями. Как я понимаю, в итоге будет установка LocalDB в виде простой инсталляции без вопросов и не требующей настройки. Так сказать "Fire and Forget" Smile

Павел 08.11.2011 20:41:36

@ Andrey, спасибо, получается что всё зависит от потребностей, т.е. если мне не нужно десяток процессов от разных приложений, то мне удобней пользоваться Express версией.
Ну и не совсем я понимаю предназначена ли она для Production использования, т.к. иногда принципиально есть сервера с SQL, а есть Application сервера, и не совсем корректно на них запускать инстансы SQL сервера

Интересно каким образом будет выглядеть установочный пакет в окончательной редакции. И будет ли возможность распространять такой вариант сервера с помощь простого копирования файлов. Например, рядом с исполняемым файлом программы лежит набора ехе и длл этого самого LocalDB, приложение стартует, поднимается отдельный процесс(sqlservr.exe) ну и дальше. Да, пусть директория с программой будет более 100 Мб, но зато какие радужные перспективы по варианту работы Portable-версии программы !

@ Павел: Разумеется от потребностей. Целевая аудитория, как говорит команда SQLServer, в первую очередь это разработчики. Чтобы было просто поставить SQLServer быстро с минимальным оверхедом. Но если ограничения не смущают, то можно использовать и в продакшене. Десктоп приложения ведь еще не ушли в прошлое.

@ serkuzm: Aга, интересно. Но как заявлено - ставится 1 копия LocalDB для всех приложений. Поэтому что-то мне подсказывает что просто копирование папки не пройдет. С другой стороны, скоро увидим.

Прочитал вашу статью. Выскажу свои соображения по поводу LocalDB. Очень напоминает вариант использования SQL Express, когда мы указываем параметры AttachDbFileName и UserInstance="true". В этом случае тоже запускается отдельный процесс сиквел сервера. Преимущество LocalDB вижу в том, что процесс установки не требует натройки, как SQL Express. Для portable версии лучше использовать Compact.

Прочитал статью, так и не понял, для чего LocalDB нужен...

@ DioNNiS: Альтернатива SQL Express, но устанавливаемая без настроек, не создающая сервиса и только с локальными подключениями. При этом, в отличии от той же Compact, поддерживается весь функционал Express, за исключением FileStream. Добавил это сравнение в статью для ясности.

Для встраиваемых систем — самое оно.

Несколько вопросов:

1. Сколько экземпляров (процессов) LocalDB будет запущено при единовременном подключении, скажем, трёх приложений к БД? Один? Три?
2. Возможна ли одновременная работа с одной и той же БД нескольких приложений?
3. Допускает ли лицензия использование LocalDB во встраиваемых решениях? Каковы вообще лицензионные ограничения?

@ Antony: Насколько мне известно
1) Один.
2) Да (но сам не экспериментировал).
3) Обещают что можно будет распространять с приложениями.

Кирилл 21.03.2012 20:45:08

Так а что по поводу производительности. Например чтение, запись больших объемов данных. Например меня очень порадовал SQL Compact 3.5 при работе с большим объемом данных лишняя память не занимается. А по скорости чтения и записи почти на уровне текстовых файлов.
Помню что с SQL Compact 4.0 дела с производительностью чуть похуже чем у 3.5 но из за некоторых фишек на это можно и закрыть глаза.
У SQL Express с памятью вообще беда или он все и вся в памяти кеширует или у меня руки не из того места растут чтобы по человечески настроить сие чудо.
Так а что с LocalDB могу я поставить её скажем на машину с 256 мб оперативной памяти и работать с таблицами по 10к - 100к записей?

@ Кирилл: Если учесть, что LocalDB это Express, но просто с другим методом запуска (exe вместо сервиса), то вывод очевиден. Хотя попробовать стоит (LocalDB ставится вместе с финальной версией SQL Express 2012 которая уже доступна).

А что по поводу  full-text search в LocalDB?

и кстати - что по поводу расширенных хранимых процедур (традиционных, не CLR)?

@ Oleg: Full-text search на LocalDb нет, т.к. в Express за это отвечает отдельный сервис. Попытка выполнить CREATE FULLTEXT INDEX ON приведет к ошибке "Cannot use full-text search in user instance".

Про расширенные хранимые процедуры не подскажу - не сталкивался. Но насколько знаю, их планируют убрать даже из самого MSSQL. Поэтому ориентироваться на них я бы не стал.

да, FTS нету, понятно.
Расширенные процедуры работают на локалДБ, проверил.
А во что неприятно поразило - нигде не написано, но в SMO некоторые проперти убрали, т.е. вообще.
При этом пуская приложение, которое работает с версиями 2005-2012 и использует SMO на локалдб оно может не работать. Я вынужден был править исходные тексты и реализовывать недостающие данные, которые не смог взять из пропертей, поскольку их не было.

Добавить комментарий