Особенности SQLite

На этой странице описаны некоторые особенности SQLite, которые отличают его от многих других движков баз SQL.

Нулевая конфигурация

SQLite не нуждается в инсталляции перед использованием. Процедура "setup" для него отсутствует. Отсутствует серверный процесс, который нуждался бы в запуске, остановке или конфигурировании. SQLite не нуждается в администраторе для создания нового экземпляра базы данных или для присвоения пользователям прав доступа. SQLite не использует конфигурационные файлы. Ничто не обязано сообщать системе о выполнении SQLite. Не требуется никаких действий для восстановления после краха системы или некорректного завершения. Здесь ничего не конфликтует.

SQLite работает просто и правильно.

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

Бессерверность

Большинство движков баз SQL выполняются как отдельные серверные процессы. Программы, желающие получить доступ к базе данных, сообщаются с сервером посредством некоторой межпроцессовой коммуникации (типично - TCP/IP), посылают серверу запрос и получают обратно результат. SQLite работает не так. В случае с SQLite, процесс, получающий доступ к базе данных, читает непосредственно из файла и пишет непосредственно в файл базы на диске. Промежуточный серверный процесс здесь отсутствует.

У бессерверности есть как преимущества, так и недостатки. Главное преимущество отсутствия отдельного серверного процесса заключается в отсутствии инсталляции, наладки, конфигурации, инициализации, управления и поиска конфликтов. Это - одна из причин, по которой SQLite имеет "нулевую конфигурацию". Программы, использующие SQLite, не нуждаются в административной поддержке для настройки движка базы данных перед своим запуском. Любая программа, которая имеет доступ к диску, может работать с базой SQLite.

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

Большинство движков баз SQL имеют клиент-серверную основу. А SQLite является единственным, насколько известно автору, бессерверным, который позволяет нескольким приложениям иметь доступ к одной и той же базе в одно и то же время.

Единственный файл базы данных

База данных SQLite есть единственный обычный дисковый файл, который может находиться где угодно в иерархии директорий. Если SQLite может читать дисковый файл, то он может читать что угодно в базе данных. Если дисковый файл и его директория открыты для записи, то SQLite может изменить что угодно в базе данных. Файлы баз данных могут быть легко скопированы на флэшку или отосланы по e-mail для совместного использования.

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

Компактность

После оптимизации размера вся библиотека SQLite со всеми возможными включениями весит менее 225KB (для ix86 измерения проводились "size"-утилитой из "GNU Compiler Suite"). Ненужные фичи могут быть отключены во время компиляции, и тогда размер библиотеки может быть сведен до 170KB.

Большинство других движков баз SQL гораздо больше этого. IBM хвастается, что ее новейший релиз движка CloudScape весит "всего" 2MB, будучи сжатым в jar-файл. Т.е. после компрессии он весит в 10 раз больше SQLite! Firebird хвастается, что его клиентская библиотека весит всего 350KB. Это на 50% больше чем SQLite и даже не содержит движка базы данных. Библиотека Berkeley DB от Sleepycat весит 450KB и не поддерживает SQL, дает программисту только простые пары "ключ-значение".

Манифестная типизация

Большинство движков баз SQL используют статическую типизацию. С каждым столбцом в таблице ассоциируется тип данных, и храниться в этом столбце могут только значения этого фиксированного типа. SQLite ослабляет это ограничение посредством манифестной типизации. В манифестной типизации тип данных является свойством самого значения, а не столбца, в котором это значение сохранено. Таким образом, SQLite позволяет пользователю сохранять любое значение любого типа в любом столбце, не обращая внимания на декларированный тип этого столбца. (Из этого правила есть некоторые исключения: Столбец INTEGER PRIMARY KEY должен содержать только целые числа. И, насколько это возможно, SQLite пытается удержать значения в декларированном типе столбца.)

Спецификация языка SQL предусматривает статическую типизацию. Поэтому некоторые люди считают, что использование манифестной типизации - баг в SQLite. Но авторы SQLite уверены, что это есть его фича. Авторы считают, что статическая типизация - баг в спецификации SQL, который пофиксен в SQLite обратно-совместимым способом.

Записи переменной длины

Большинство других движков баз SQL забирают фиксированный объем дискового пространства под каждую строку в большинстве таблиц. Они идут на специальные уловки для обработки BLOB-ов и CLOB-ов, которые могут иметь произвольную длину. Но в большинстве таблиц, если вы декларировали VARCHAR(100), то движок базы данных будет резервировать 100 байт дискового пространства независимо от количества информации, которое вы сохраняете в этом столбце.

SQLite, напротив, использует ровно столько дискового пространства, сколько нужно для сохранения информации в строке. Если вы сохраняете единственный символ в колонке VARCHAR(100), значит, будет израсходован только один байт дискового пространства. (Вернее - два байта с учетом накладных расходов, - в начало каждого столбца записи пишется его тип данных и длина.)

Использование в SQLite записей переменной длины имеет несколько преимуществ. Очевидно, что в результате уменьшаются файлы баз данных. Кроме того, ускоряется работа базы данных, из-за уменьшения информации приходится меньше перемещаться туда-сюда по диску. Наконец, использование переменной длины записей позволяет SQLite использовать манифестную типизацию вместо статической типизации.

Читабельный исходный код

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

Предложения SQL компилируются в код виртуальной машины

Каждый движок баз SQL компилирует каждое предложение SQL во внутреннюю структуру данных некоторого типа, и потом использует ее для выполнения работы предложения. Но в большинстве движков SQL эта внутренняя структура данных является запутанной сетью взаимосвязанных структур и объектов. В SQLite скомпилированная форма предложений является короткой программой, написанной на подобии машинного языка. Пользователи базы данных могут просмотреть этот язык виртуальной машины, добавив к запросу ключевое слово EXPLAIN.

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

Всеобщее достояние

Исходный код SQLite является общественным достоянием. При использовании какой-либо части исходного кода ядра не возникает никаких проблем с копирайтом. (Документация и коды тестов - отдельная история, - некоторые части документации и тесты управляются лицензиями "open-source".) Все контрибьюторы ПО ядра SQLite письменно отрекаются от любого копирайта на код. Поэтому кто угодно может легально сделать что угодно с исходным кодом SQLite.

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

Файлы исходного кода других движков баз SQL обычно начинаются с комментария, описывающего ваши лицензионные права на просмотр и копирование этого файла. Исходный код SQLite не содержит лицензии, так как не управляется копирайтом. Вместо лицензии, исходный код SQLite содержит благословение:

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

Расширения языка SQL

SQLite поддерживает несколько дополнений к языку SQL, которые не являются нормой в других движках баз данных. Ключевое слово EXPLAIN и манифестная типизация уже упоминались выше. SQLite поддерживает такие конструкции как REPLACE и ON CONFLICT, которые позволяют управлять разрешением конфликтов ограничений. SQLite поддерживает команды ATTACH и DETACH, которые позволяют в одном и том же запросе использовать несколько независимых баз данных. Кроме того, SQLite определяет API, которое позволяет пользователям добавлять новые функции SQL и последовательности сортировки.

Перевод с английского - Дмитрий Скоробогатов, 21.12.2006.

Оригинальный текст можно найти по адресу http://sqlite.org/different.html.