Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.
Небольшая вводная.
Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка и ответов поскольку информации очень много и так хоть немного проще ее структурировать.
Что такое SQLite?
SQLite — это встраиваемая кроссплатформенная БД, которая поддерживает достаточно полный набор команд SQL и доступна в исходных кодах (на языке C).
Исходные коды SQLite находятся в public domain, то есть вообще никаких ограничений на использование.
Сайт (с прекрасной документацией на английском): http://sqlite.org
Текущая версия: 3.7.13
SQLite можно скомпилировать самому, но я скачиваю ее уже скомпилированную в виде Windows DLL.
Страница скачивания: http://sqlite.org/download.html
Для собственной сборки обычно скачивают т.н. «amalgamation»,
т.е. исходники SQLite в виде единого файла на языке C + sqlite3.h.
Чтобы уменьшить размер кода SQlite, выкинув ненужные ништяки, используются всякие DEFINE.
Насколько SQLite популярна?
Кратко: она везде. Как минимум, на любом смартфоне.
Насколько она надежна?
Очень. При выпуске версии она проходит через ряд серьезнейших автоматических тестов (проводится ~ 2 млн тестов), покрытие кода тестами 100% (с августа 2009).
А какие еще инструменты дают разработчики?
Доступна консольная утилита для работы с базами (sqlite3.exe, «a command-line shell for accessing and modifying SQLite databases»).
И все?
Да, от основных разработчиков — все. Однако, другие люди пишут всякие менеджеры и пр.
Лично я так и не нашел идеального и пользуюсь консолью.
Что значит «достаточно полный набор SQL»?
Как известно, в своем развитии SQL устремился в разные стороны. Крупные производители начали впихивать всякие расширения. И хотя принимаются всякие стандарты (SQL 92), в реальной жизни все крупные БД не поддерживают стандартов полностью + имеют что-то свое. Так вот, SQLite старается жить по принципу «минимальный, но полный набор». Она не поддерживает сложные штуки, но во многом соответствует SQL 92.
И вводит некие свои особенности, которые очень удобны, но — не стандартны.
Что конкретно в поддержке SQL может вызвать недоумение?
Нельзя удалить или изменить столбец в таблице (ALTER TABLE DROP COLUMN…, ALTER TABLE ALTER COLUMN… ).
Есть триггеры, но не настолько мощные как у крупных RDBMS.
Есть поддержка foreign key, но по умолчанию — она ОТКЛЮЧЕНА.
Нет встроенной поддержки UNICODE (но ее, вообщем, нетрудно добиться).
Нет хранимых процедур.
А что своего хорошего или необычного?
a) каждая запись содержит виртуальный столбец rowid, который равен 64-битному номеру (уникальному для таблицы).
Можно объявить свой столбец INTEGER PRIMARY KEY и тогда этот столбец станет rowid (со своим именем, имя rowid все равно работает).
При вставке записи можно указать rowid, а можно — не указывать (и система тогда вставит уникальный).
Подробности: www.sqlite.org/autoinc.html
b) можно без труда организовать БД в памяти (это очень удобно и чуть позже расскажу подробнее);
c) легко переносить: по умолчанию, БД — это один файл (в кроссплатформенном формате);
d) тип столбца не определяет тип хранимого значения в этом поле записи, то есть в любой столбец можно занести любое значение;
e) много встроенных функций (которые можно использовать в SQL): www.sqlite.org/lang_corefunc.html;
Не понял — что там с типом? Зачем нужен тип столбца тогда вообще?
Тип столбца определяет как сравнивать значения (нужно же их привести к единому типу при сравнении, скажем, внутри индекса).
Но не обязывает заносить значения именно такого типа в столбец. Нечто вроде weak typing.
Допустим, мы объявили столбец как «A INTEGER».
SQlite позволяет занести в этот столбец значения любого типа (999, «abc», «123», 678.525).
Если вставляемое значение — не целое, то SQlite пытается привести его к целому.
Т.е. строка «123» превратится в целое 123, а остальные значения запишутся «как есть».
Так можно вообще не задавать тип столбца?
Очень часто так и делается: CREATE TABLE foo (a,b,c,d).
А как с архитектурой? Сервера-то нету?
Сервера нету, само приложение является сервером. Доступ к БД происходит через «подключения» к БД (нечто вроде хэндла файла ОС), которые мы открываем через вызов соот-й функции DLL. При открытии указывается имя файла БД. Если такого нету — он автоматически создается.
Допустимо открывать множество подключений к одной и тоже БД (через имя файла) в одном или разных приложениях.
Система использует механизмы блокировки доступа к файлу на уровне ОС, чтобы это все работало
(эти механизмы обычно плохо работают на сетевых дисках, так что не рекомендуется использовать SQlite с файлом на сети).
Изначально SQlite работал по принципу «многие читают — один пишет».
То есть только одно соединение пишет в БД в данный момент времени. Если другие соединения попробуют тоже записать, то словят ошибку SQLITE_BUSY.
Можно, однако, ввести таймаут операций. Тогда подключение, столкнувшись с занятостью БД, будет ждать N секунду прежде, чем отвалиться с ошибкой SQLITE_BUSY.
И как быть?
Либо одно подключение и все запросы через него, либо исходить из возможного таймаута и предусмотреть повтор выполнения SQL.
Есть и еще одна возможность: не так давно появился новый вид лога SQlite: Write Ahead Log, WAL.
Если включить для БД именно этот режим лога, то несколько подключений смогут одновременно модифицировать БД.
Но в этом режиме БД уже занимает несколько файлов.
Ну понятно теперь почему SQLite — ужасна, ведь у нее нет ГЛОБАЛЬНОГО КЭША?
Действительно, все современные RDBMS немыслимы без глобального разделяемого кэша, который может хранить всякие ништяки вроде скомпилированных параметризованных запросов. Этим занят сервер, которого тут нет. Однако, в рамках одного приложения SQlite может разделять кэш между несколькими подключениями (читать тут: www.sqlite.org/sharedcache.html) и немного сэкономить память.
А почему все жалуются, что SQLite — тормозит?
Две причины. Первая — настройки по умолчанию. Они работают на надежность, а не на производительность.
Вторая — непонимание механизма фиксации транзакций. По умолчанию после любой команды SQlite будет фиксировать транзакцию (то есть ожидать пока БД окажется в целостном состоянии для отключения питания). В зависимости от режима паранойи SQLite потратит на это от 50 до 300 мс (ожидая окончания записи данных на диск).
Что делать-то? Мне нужно вставить 100 тыс записей и быстро!
Удалить индексы, включить режим синхронизации OFF (или NORMAL), вставлять порциями по N тысяч (N — подобрать, для начала взять 5000). Перед вставкой порции сделать BEGIN TRANSACTION, после — COMMIT.
А вот я нашел ошибку! Как рапортовать?
Никак.
Дело в том, что популярность SQLite страшна — она везде. Это не шутка.
И разработчики столкнулись с валом сообщений об ошибках, которые либо были вызваны непониманием, либо являлись скрытым feature request. Они, фактически, закрыли прямой прием репортов с ошибками.
Так что следует подписаться на список рассылки и описать там проблему и надеятся на лучшее.
Лично у меня возникла ситуация, которую я трактовал как дефект SQLIte. Я описал это в рассылке. В следующей версии поведение SQLite было исправлено.
Продолжение следует.
Автор: Krovosos
