SQLite как формат файлов приложения

Содержание

1. Краткое изложение

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

Упрощение разработки приложений
Документы в одном файле
Язык запросов высокого уровня
Доступность содержимого
Кроссплатформенность
Атомарные транзакции
Постепенные и непрерывные обновления
Простота расширения
Производительность
Совместное использование несколькими процессами
Несколько языков программирования
Более качественные приложения

Каждый из этих пунктов будет подробнее рассмотрен ниже, после того как мы сначала внимательнее разберём значение понятия «формат файлов приложения». См. также краткую версию этой статьи.

2. Что такое формат файлов приложения?

«Формат файлов приложения» — это формат файлов, используемый для сохранения состояния приложения на диске или обмена информацией между программами. Сегодня используются тысячи форматов файлов приложений. Вот лишь несколько примеров:

DOC — документы Word Perfect и Microsoft Office
DWG — чертежи AutoCAD
PDF — Portable Document Format компании Adobe
XLS — электронные таблицы Microsoft Excel
GIT — репозиторий исходного кода Git
EPUB — формат электронных публикаций, используемый электронными книгами, кроме Kindle
ODT — формат Open Document, используемый OpenOffice и другими программами
PPT — презентации Microsoft PowerPoint
ODP — формат презентаций Open Document, используемый OpenOffice и другими программами

Мы различаем «формат файла» и «формат приложения». Формат файла используется для хранения одного объекта. Например, файл GIF или JPEG хранит одно изображение, а файл XHTML хранит текст, поэтому это «форматы файлов», а не «форматы приложений». Файл EPUB, напротив, хранит и текст, и изображения (в виде входящих в него файлов XHTML и GIF/JPEG), поэтому его считают «форматом приложения». Эта статья посвящена «форматам приложений».

Граница между форматом файла и форматом приложения размыта. В этой статье JPEG называется форматом файла, но для редактора изображений JPEG можно считать форматом приложения. Многое зависит от контекста. Для целей этой статьи будем считать, что формат файла хранит один объект, а формат приложения — множество различных объектов и связи между ними.

Большинство форматов приложений относится к одной из трёх категорий:

Полностью пользовательские форматы. Пользовательские форматы специально разрабатываются для одного приложения. DOC, DWG, PDF, XLS и PPT — примеры пользовательских форматов. Для удобства переноса пользовательские форматы обычно хранятся в одном файле. Как правило, они также являются двоичными, хотя формат DWG представляет собой заметное исключение. Для чтения и записи пользовательских форматов требуются специализированные прикладные программы; обычно такие форматы недоступны из общедоступных инструментов, таких как программы командной строки unix и текстовые редакторы. Иными словами, пользовательские форматы обычно представляют собой «непрозрачные блоки данных». Чтобы получить доступ к содержимому файла пользовательского формата приложения, нужен инструмент, специально предназначенный для чтения и/или записи данных в этом формате.
Форматы-наборы файлов. Иногда состояние приложения хранится в виде иерархии файлов. Яркий пример — Git, хотя такое решение часто встречается и в отдельных специализированных приложениях. Формат-набор файлов по сути использует файловую систему как базу данных «ключ/значение», храня небольшие фрагменты информации в отдельных файлах. Это упрощает доступ к содержимому с помощью распространённых служебных программ, таких как текстовые редакторы или «awk» и «grep». Но даже если многие файлы в таком формате легко читаются, обычно некоторые из них имеют собственный формат (например, Git «Packfiles») и поэтому являются «непрозрачными блоками данных», которые нельзя прочитать или записать без специализированных инструментов. Кроме того, переместить набор файлов из одного места или с одного компьютера на другой гораздо менее удобно, чем переместить один файл. Например, набор файлов сложно вложить в электронное письмо. Наконец, формат-набор файлов нарушает «метафору документа»: нет единого файла, на который пользователь мог бы указать как на «документ».
Упакованные форматы-наборы файлов. В некоторых приложениях используется набор файлов, который затем помещается в контейнер одного файла, обычно в ZIP-архив. EPUB, ODT и ODP — примеры такого подхода. Книга EPUB на самом деле представляет собой ZIP-архив, содержащий различные файлы XHTML с текстом глав, изображения GIF и JPEG для иллюстраций и специальный файл каталога, который указывает программе для чтения электронных книг, как связаны между собой все файлы XML и изображений. Документы OpenOffice (ODT и ODP) также являются ZIP-архивами, содержащими XML и изображения, представляющие их содержимое, а также файлы «каталога», описывающие взаимосвязи между составными частями.

Упакованный формат-набор файлов — это компромисс между полностью пользовательским форматом файла и обычным форматом-набором файлов. Упакованный формат-набор файлов не является непрозрачным блоком данных в том же смысле, что и пользовательский формат, поскольку его составные части по-прежнему доступны с помощью любого распространённого ZIP-архиватора. Однако он не так доступен, как обычный формат-набор файлов: для работы всё равно нужен ZIP-архиватор, а инструменты командной строки вроде «find» обычно нельзя применять к иерархии файлов, пока она не будет распакована. С другой стороны, упакованный формат-набор файлов сохраняет метафору документа, помещая всё содержимое в один файл на диске. Кроме того, благодаря сжатию упакованный формат-набор файлов обычно занимает меньше места.

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

Цель этого документа — обосновать необходимость четвёртой, новой категории форматов файлов приложений: файла базы данных SQLite.

3. SQLite как формат файлов приложения

Любое состояние приложения, которое можно записать в набор файлов, можно также сохранить в базе данных SQLite с простой схемой «ключ/значение», например такой:

CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);

Если содержимое сжато, такая база данных архива SQLite имеет тот же размер (±1%), что и эквивалентный ZIP-архив, и при этом позволяет обновлять отдельные «файлы», не перезаписывая весь документ.

Но база данных SQLite не ограничивается простой структурой «ключ/значение», как база данных на основе набора файлов. База данных SQLite может содержать десятки, сотни или тысячи разных таблиц, в каждой из которых — десятки, сотни или тысячи полей с различными типами данных, ограничениями и значениями; все таблицы могут ссылаться друг на друга, иметь подходящие и автоматически создаваемые индексы для быстрого поиска, а данные при этом эффективно и компактно хранятся в одном файле на диске. Кроме того, вся эта структура кратко документирована для людей в схеме SQL.

Иными словами, база данных SQLite может делать всё, что доступно формату-набору файлов или упакованному формату-набору файлов, и даже больше, причём более наглядно. База данных SQLite — более универсальный контейнер, чем файловая система «ключ/значение» или ZIP-архив. (Подробный пример см. в статье разбор примера с OpenOffice.)

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

Поэтому по сравнению с другими подходами использование базы данных SQLite в качестве формата файлов приложения имеет существенные преимущества. Ниже перечислены некоторые из них и приведены пояснения:

Упрощение разработки приложений. Для чтения или записи файла приложения не нужно писать новый код. Достаточно подключить библиотеку SQLite или добавить единый исходный файл «sqlite3.c» к остальному коду приложения на C, и SQLite возьмёт на себя весь ввод-вывод файлов приложения. Это может сократить код приложения на многие тысячи строк и соответственно снизить затраты на разработку и сопровождение.

SQLite — одна из наиболее широко используемых программных библиотек в мире. Ежедневно применяются буквально десятки миллиардов файлов баз данных SQLite — на смартфонах и других устройствах, а также в настольных приложениях. SQLite тщательно тестируется и доказала свою надёжность. Этому компоненту не требуется много настройки или отладки, поэтому разработчики могут сосредоточиться на логике приложения.
Документы в одном файле. База данных SQLite хранится в одном файле, который легко копировать, перемещать или прикреплять. Метафора «документа» сохраняется.

SQLite не предъявляет требований к именованию файлов, поэтому приложение может использовать любой собственный суффикс файла, чтобы обозначить, что файл «принадлежит» этому приложению. В заголовках файлов баз данных SQLite содержится 4-байтовый идентификатор приложения, которому можно присвоить определённое приложением значение, а затем использовать его для определения «типа» документа такими служебными программами, как file(1), что ещё лучше сохраняет метафору документа.
Язык запросов высокого уровня. SQLite — полноценный механизм реляционной базы данных, а значит, приложение может получать доступ к содержимому с помощью запросов высокого уровня. Разработчикам приложений не нужно тратить время на размышления о том, «как» извлечь из документа нужную информацию. Разработчики могут написать SQL-запрос, описывающий, «какую» информацию они хотят получить, и предоставить механизму базы данных возможность определить, как лучше всего извлечь это содержимое. Это помогает разработчикам смотреть на задачу в целом и сосредоточиться на решении проблемы пользователя, не отвлекаясь на низкоуровневые детали формата файлов.

Формат-набор файлов можно рассматривать как базу данных «ключ/значение». Такая база данных лучше, чем отсутствие базы данных вообще. Но без транзакций, индексов, языка запросов высокого уровня и подходящей схемы использовать базу данных «ключ/значение» гораздо сложнее и рискованнее, чем реляционную базу данных.
Доступность содержимого. Информацию из файла базы данных SQLite можно просматривать с помощью общедоступных инструментов командной строки с открытым исходным кодом: эти инструменты по умолчанию установлены в системах Mac и Linux и доступны для Windows в виде автономного EXE-файла. В отличие от пользовательских форматов файлов, для чтения или записи содержимого базы данных SQLite не нужны программы, специфичные для приложения. Файл базы данных SQLite не является непрозрачным блоком данных. Текстовые редакторы или такие инструменты, как «grep» и «awk», и правда не подходят для работы с базой данных SQLite, но язык запросов SQL — гораздо более мощный и удобный способ изучать её содержимое, поэтому невозможность использовать «grep», «awk» и подобные инструменты не считается потерей.

База данных SQLite — это чётко определённый и подробно документированный формат файла, широко используемый буквально миллионами приложений. Он обратно совместим с момента своего появления в 2004 году и, как ожидается, останется совместимым ещё десятилетия. Долговечность файлов баз данных SQLite особенно важна для специализированных приложений, поскольку позволяет получать доступ к содержимому документа и в далёком будущем, когда от исходного приложения уже не останется и следа. Данные живут дольше кода. Библиотека Конгресса США рекомендует базы данных SQLite в качестве формата хранения для долгосрочного сохранения цифрового содержимого.
Кроссплатформенность. Файлы баз данных SQLite переносимы между 32- и 64-разрядными компьютерами, между архитектурами с прямым и обратным порядком байтов, а также между различными вариантами операционных систем Windows и Unix-подобных систем. Приложение, использующее формат файлов SQLite, может хранить двоичные числовые данные, не беспокоясь о порядке байтов целых чисел или чисел с плавающей точкой. Текстовое содержимое можно читать или записывать в UTF-8, UTF-16LE или UTF-16BE, а SQLite автоматически выполняет необходимые преобразования на лету.
Атомарные транзакции. Записи в базу данных SQLite атомарны. Они либо выполняются полностью, либо не выполняются вовсе — даже при сбоях системы или отключении питания. Поэтому документ не будет повреждён лишь потому, что электричество отключилось в тот самый момент, когда изменение записывалось на диск.

SQLite поддерживает транзакции: несколько изменений можно сгруппировать так, чтобы они либо применились все, либо не применилось ни одно из них; если до фиксации обнаружится проблема, изменения можно отменить. Благодаря этому приложение может постепенно вносить изменения, а затем выполнять различные проверки корректности и согласованности полученных данных до фиксации изменений на диске. DVCS Fossil использует этот приём, чтобы перед каждым изменением проверять, не была ли утрачена история репозитория.
Постепенные и непрерывные обновления. При записи в файл базы данных SQLite на диск записываются только те части файла, которые действительно изменились. Благодаря этому запись выполняется быстрее и снижается износ SSD. Это огромное преимущество перед пользовательскими и упакованными форматами-наборами файлов: для изменения одного байта в обоих случаях обычно приходится перезаписывать весь документ. Обычные форматы-наборы файлов тоже в некоторой степени поддерживают постепенные обновления, однако обычно размер записываемых данных у них больше (один файл), чем у SQLite (одна страница).

SQLite также поддерживает непрерывное обновление. Вместо того чтобы накапливать изменения в памяти и записывать их на диск только после команды «Файл/Сохранить», можно записывать изменения на диск по мере их появления. Это помогает избежать потери работы при сбое системы или отключении питания. Автоматизированный стек отмены и повтора, управляемый с помощью триггеров, можно хранить в базе данных на диске, благодаря чему отмена и повтор действий доступны и между сеансами.
Простота расширения. По мере развития приложения в формат файлов приложения SQLite можно добавлять новые возможности, просто добавляя новые таблицы в схему или новые столбцы в существующие таблицы. Добавление столбцов или таблиц не меняет смысл прежних запросов, поэтому при небольшой осторожности, необходимой для сохранения значения устаревших столбцов и таблиц, сохраняется обратная совместимость.

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

Формат-набор файлов, как и SQLite, можно читать постепенно. Однако многих разработчиков удивляет, что SQLite может считывать из базы данных и записывать в неё небольшие BLOB-объекты (размером менее примерно 100 КБ) быстрее, чем те же объекты можно считывать или записывать в виде отдельных файлов в файловой системе. (Дополнительные сведения см. в статьях На 35% быстрее файловой системы и Внутренние и внешние BLOB-объекты.) Использование механизма реляционной базы данных связано с накладными расходами, однако не следует считать, что прямой файловый ввод-вывод быстрее ввода-вывода базы данных SQLite: часто это не так.

В любом случае, если в приложении SQLite возникнут проблемы с производительностью, часто их можно решить, добавив одно или два оператора CREATE INDEX в схему или, возможно, один раз выполнив ANALYZE, не изменяя ни одной строки кода приложения. Но если проблема с производительностью возникает при использовании пользовательского формата или формата-набора файлов, для её устранения часто приходится значительно изменять код приложения, добавляя новые индексы и поддерживая их в актуальном состоянии либо извлекая информацию с помощью других алгоритмов.
Совместное использование несколькими процессами. SQLite автоматически координирует параллельный доступ нескольких потоков и/или процессов к одному документу. Два или более приложения могут одновременно подключаться к одному документу и читать из него данные. Записи выполняются последовательно, но обычно занимают всего несколько миллисекунд, поэтому приложения просто пишут по очереди. SQLite автоматически следит за тем, чтобы низкоуровневый формат документа не повреждался. Для пользовательского формата или формата-набора файлов аналогичная функциональность, напротив, требует значительной поддержки в приложении. Кроме того, логика приложения, необходимая для поддержки параллельного доступа, печально известна своей склонностью порождать ошибки.
Несколько языков программирования. Хотя сама SQLite написана на ANSI-C, интерфейсы существуют почти для любого другого языка программирования, который можно назвать: C++, C#, Objective-C, Java, Tcl, Perl, Python, Ruby, Erlang, JavaScript и так далее. Поэтому программисты могут разрабатывать приложения на том языке, которым им удобнее всего пользоваться и который лучше всего соответствует требованиям проекта.

Формат файлов приложения SQLite отлично подходит для случаев, когда существует набор или «объединение» отдельных программ, часто написанных на разных языках и разными командами разработчиков. Такая ситуация часто встречается в исследовательских или лабораторных средах, где одна команда отвечает за сбор данных, а другие — за различные этапы анализа. Каждая команда может использовать наиболее подходящие для неё оборудование, операционную систему, язык программирования и методологию разработки; если все программы используют базу данных SQLite с общей схемой, они смогут взаимодействовать друг с другом.
Более качественные приложения. Если форматом файла приложения является база данных SQLite, полная документация этого формата состоит из схемы базы данных и, возможно, нескольких дополнительных пояснений о том, что представляет собой каждая таблица и каждый столбец. Описание пользовательского формата файла, напротив, обычно занимает сотни страниц. Формат-набор файлов, хотя его гораздо проще описать, чем полностью пользовательский формат, всё же обычно намного объёмнее и сложнее дампа схемы SQL, поскольку необходимо описать названия и форматы отдельных файлов.

Это не мелочь. Чёткий, краткий и понятный формат файла — важнейшая составляющая разработки любого приложения. Фред Брукс в своей самой продаваемой книге по информатике за всё время, Мифический человеко-месяц, пишет:

Представление — сущность программирования.
...
Покажите мне свои блок-схемы, но скройте таблицы — и я так и останусь в недоумении. Покажите мне таблицы — и блок-схемы обычно мне не понадобятся: они будут очевидны.

Роб Пайк в своих Правилах программирования выражает ту же мысль так:

Главное — данные. Если вы выбрали правильные структуры данных и хорошо их организовали, алгоритмы почти всегда будут очевидны. В программировании главное — структуры данных, а не алгоритмы.

Линус Торвальдс выразил ту же мысль другими словами в списке рассылки Git 2006-06-27:

Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и связях между ними.

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

4. Вопросы безопасности

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

Существуют атаки, которые изобретательный злоумышленник может провести против приложения, обманом заставив пользователя открыть файл приложения, представляющий собой базу данных SQLite. Однако несколько простых мер предосторожности позволяют предотвратить серьёзное проникновение или ущерб. Если вы решили использовать SQLite (или любую реляционную базу данных) в качестве формата файлов приложения, ознакомьтесь с документом о защите от тёмных искусств, особенно с разделом о недоверенных файлах баз данных, чтобы убедиться, что вы приняли разумные меры защиты и случайно не оставили брешей в безопасности.

5. Заключение

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

Последнее обновление этой страницы: 2026-04-08 07:39:58Z

SQLite is in the Public Domain.
https://sqlite.org/appfileformat.html