Встраиваемая СУБД

Встраиваемая система управления базами данных — архитектура систем управления базами данных, когда СУБД тесно связана с прикладной программой и работает на том же компьютере, не требуя профессионального администрирования.

Встраиваемые СУБД применяются во многих программах, которые хранят большие массивы данных, но при этом не требуется доступ с многих компьютеров. На «рабочем столе» неопытного пользователя тоже есть программы, в которых может найтись встраиваемая СУБД: почтовые клиенты и мессенджеры (базы переписки)^[1], медиапроигрыватели (плейлисты и обложки)^[2], просмотрщики изображений (метаданные и уменьшенные эскизы)^[3], различные локальные БД наподобие телефонных справочников и геоинформационных систем (предоставляемые данные).

Исторически локальные и файл-серверные СУБД предоставляли скриптовый язык, на котором пользователь мог писать прикладную программу. Так устроены Microsoft Access, FoxPro, Clipper, файл-серверные версии 1С: Бухгалтерии. Недостатком этого подхода была крайняя бедность результирующих программ, ограниченные средства отладки. И зачастую не существовало компактной среды исполнения, которую можно распространять вместе с программой; нужна программа — устанавливай весь пакет. С распространением динамической линковки и opensource-сообщества маятник качнулся в другую сторону: пусть программист пишет свою программу на том языке высокого уровня, на котором удобно. СУБД же будет подсоединена к программе и станет единым целым с ней.

Особенности

Нет отдельной программы-сервера 

Физически встраиваемая СУБД является библиотекой, статически или динамически подсоединённой к основной программе. Программа и СУБД общаются не через сетевые сокеты, а через специализированное API.^[4][5]. В этом, правда, есть и недостаток: зачастую программист сам должен не допускать многопоточных гонок.

Высокая скорость и малый расход памяти, особенно на длинных строках и BLOBах 

Благодаря специализированному API количество операций чтения-записи минимально.

Как правило, специализированный язык запросов или неполная совместимость с SQL-92 

В угоду производительности часто разработчики реализуют или неполный SQL (SQLite)^[6], или специализированный язык запросов (BerkeleyDB). К тому же встраиваемые СУБД могут действовать совсем по другому принципу, чем клиент-серверные: пинг к БД нулевой, и запрос можно выполнять по частям, несколькими обращениями к СУБД.

Как правило, нет пользовательских прав^[6]; простейшая изоляция транзакций 

Большего однопользовательской БД и не нужно. Как правило, транзакции изолируются по принципу «записываем по одному» с помощью стандартных механизмов ОС наподобие блокировки файлов. Доступ к одному файлу из нескольких программ наладить можно: так, SQLite успешно работает в малонагруженных сайтах.^[7] Но высокая нагрузка ему не по зубам.

Как правило, нет архивации и репликации БД 

Встраиваемая БД надёжна настолько, насколько надёжна библиотека СУБД и файловая система, на которой база данных располагается. Известные встраиваемые СУБД, как правило, хорошо оттестированы,^[8] а современные файловые системы очень надёжны. Тем не менее, есть множество способов потерять данные, так что такие решения по надёжности уступают серверным СУБД.

Как правило, нет языковых средств, упрощающих доступ к БД 

Специализированные СУБД-языки наподобие xBase обычно представляют собой симбиоз языка запросов и языка прикладного программирования. В языках программирования общего назначения правильность запроса будет проверена не при компиляции, а лишь тогда, когда запрос будет послан в СУБД. И, конечно же, на языке программирования общего назначения конструкции доступа к БД (как встраиваемой, так и клиент-серверной) будут тяжеловесными.

Как правило, планы запросов отделены от их параметров и находятся под управлением программиста 

В SQLite, например, принят такой механизм: программист передаёт в СУБД SQL-запрос с «заглушками» для параметров и получает объект «откомпилированный запрос». Затем он сам, командой bind, подставляет в этот объект нужные параметры. Это упрощает СУБД (не нужен кэш запросов) и повышает надёжность ПО (полностью исключаются ошибки экранирования). Клиент-серверные ПО не могут позволить себе такого из-за злонамеренных клиентов, задержек сети и более жёсткой стандартизации.

Примеры

• Accuracer Database System
• Advantage Database Server
• CSQL
• EffiProz
• ElevateDB
• Встраиваемая версия InnoDB
• Empress Embedded Database
• Extensible Storage Engine
• eXtremeDB
• Встраиваемая версия Firebird
• HSQLDB
• InfinityDB
• Встраиваемая версия Informix Dynamic Server
• Встраиваемая версия InterBase
• ITTIA DB
• Kyoto Cabinet
• NexusDB
• Oracle Berkeley DB
• RDM Embedded
• ScimoreDB
• SolidDB
• SQLite
• Microsoft SQL Server Compact
• TurboDB
• Valentina DB
• VistaDB

Примечания

1. ↑ В частности, Skype использует SQLite для хранения баз переписки
2. ↑ В частности, AIMP использует SQLite для хранения плейлистов
3. ↑ В частности, XnView хранит в базе SQLite эскизы и тэги
4. ↑ Пример API BerkeleyDB (англ.)
5. ↑ Пример API SQLite (англ.)
6. ↑ ^{1 2} Чего нет в SQLite (англ.)
7. ↑ Применение SQLite (англ.)
8. ↑ Как тестируется SQLite (англ.)

Для улучшения этой статьи желательно?: Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.