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

(Примечание: Настоящая страница содержит краткое описание причин, по которым SQLite является подходящим форматом файла приложения. Данная тема рассматривается более подробно в отдельной технической заметке.)

SQLite успешно используется в качестве формата файла на диске для настольных приложений, таких как системы контроля версий, инструменты финансового анализа, пакеты для каталогизации и редактирования медиа, пакеты САПР, программы ведения записей и так далее. Традиционные вызовы File/Open используют sqlite3_open() для подключения к файлу базы данных. Обновления происходят автоматически по мере изменения содержимого приложения, поэтому опция File/Сохранить становится излишней. Опцию File/Сохранить как можно реализовать, используя API резервного копирования.

Существует множество преимуществ использования SQLite в качестве формата файла приложения, включая:

1. Лучшая производительность
   • Чтение и запись из базы данных SQLite часто быстрее, чем чтение и запись отдельных файлов с диска. См. 35% быстрее, чем файловая система и Внутренние и внешние BLOB.
   • Приложению требуется загружать только необходимые данные, а не весь файл и хранить полное разборку в памяти.
   • Небольшие правки перезаписывают только те части файла, которые изменяются, уменьшая время записи и износ SSD-дисков.
2. Сокращение затрат и сложности приложения
   • Нет необходимости писать и отлаживать код ввода/вывода файла приложения.
   • Доступ к содержимому и его обновление можно осуществлять с помощью кратких запросов SQL вместо длинных и подверженных ошибкам процедурных процедур.
   • Формат файла можно расширить в будущих выпусках, просто добавив новые таблицы и/или столбцы, сохранив обратную совместимость.
   • Приложения могут использовать индексы полнотекстового поиска и RTREE и использовать триггеры для реализации автоматизированной стеки undo/redo.
   • Проблемы с производительностью часто можно решить даже на поздних этапах разработки, используя CREATE INDEX, избегая дорогостоящих перепроектировок, переписываний и повторных тестов.
3. Переносимость
   • Файл приложения переносится на все операционные системы, 32- и 64-разрядные архитектуры, а также big- и little-endian архитектуры.
   • Объединение программ, возможно, написанных на разных языках программирования, может получить доступ к одному файлу приложения без проблем совместимости.
   • Несколько процессов могут подключаться к одному файлу приложения и читать и записывать, не мешая друг другу.
   • Разнообразное содержимое, которое в противном случае хранилось бы как «куча файлов», упаковывается в один файл на диске для упрощения передачи через scp/ftp, USB-накопитель и/или вложение в электронное письмо.
4. Надежность
   • Содержимое может быть обновлено непрерывно и атомарно, так что при отключении питания или сбоях практически не теряется работа.
   • Ошибок в SQLite намного меньше, чем в коде ввода/вывода файлов, написанном вручную.
   • Запросы SQL намного короче, чем эквивалентный процедурный код, а поскольку количество ошибок на строку кода примерно постоянное, это означает меньше ошибок в целом.
5. Доступность
   • Содержимое базы данных SQLite можно просматривать с помощью широкого спектра сторонних инструментов.
   • Содержимое, хранящееся в базе данных SQLite, с большей вероятностью будет восстановлено через десятилетия, долго после того, как все следы исходного приложения исчезнут. Данные живут дольше кода.
   • Файлы баз данных SQLite рекомендуются Библиотекой Конгресса США в качестве формата хранения для долгосрочного сохранения цифрового контента.

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

Эта страница была в последний раз изменена 08.01.2022 05:02:57 UTC