 |
|
|
|
|
| WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
|
|
|
|
|
|
| WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
Файл базы данных SQLite с определенной схемой часто делает превосходный
формат файла приложения. Вот дюжина причин, почему это так:
Каждый из этих пунктов будет описан более подробно ниже после первого
рассмотрения более тесно значения "формата файла приложения".
См. также здесь.
"Формат файла приложения" является форматом файла, используемым,
чтобы сохранить состояние приложения или обменять информацию между
программами. Есть тысячи форматов файла. Вот всего несколько примеров:
Мы делаем различие между "форматом файла" и "прикладным
форматом". Формат файла используется, чтобы хранить отдельный объект.
Так, например, GIF или JPEG хранит единственное изображение и
XHTML хранит текст, таким образом, это "форматы файлов", но не
"прикладные форматы". Файл EPUB, напротив, хранит текст и
изображения (XHTML и GIF/JPEG) таким образом, это считают "прикладным
форматом". Эта статья о "прикладных форматах".
Граница между форматом файла и прикладным форматом нечетка. Эта статья
называет JPEG форматом файла, но для редактора изображений JPEG можно было бы
считать прикладным форматом. Много зависит от контекста. Для этой статьи
давайте скажем, что формат файла хранит отдельный объект, а прикладной формат
хранит много различных объектов и их отношения друг к другу.
Большинство прикладных форматов вписывается в одну из этих трех категорий:
Полностью свои форматы. Такие форматы специально
предназначены для отдельного приложения. DOC, DWG, PDF, XLS и PPT
это примеры своих форматов. Такие форматы обычно содержатся в единственном
файле, для простоты транспортировки. Они также обычно двоичные,
хотя формат DWG существенное исключение.
Свои форматы файлов требуют, чтобы код специализированного приложения
читал и писал их, обычно они недоступны из внешних
инструментов, таких как программы командной строки Unix и текстовые
редакторы. Другими словами, свои форматы обычно "непрозрачные blob".
Чтобы получить доступ к содержанию формата файла пользовательского
приложения, каждому нужен инструмент, определенно спроектированный, чтобы
прочитать и/или написать тот формат.
Форматы груды файлов.
Иногда состояние приложения сохранено как иерархия файлов. Git это главный
пример этого, хотя явление происходит часто. Формат груды файлов по существу
использует файловую систему в качестве базы данных ключа/значения, храня
маленькие куски информации в отдельных файлах.
Это дает преимущество создания содержания, более доступного для общих утилит,
таких как текстовые редакторы, "awk" или "grep".
Но даже если многие файлы в формате груды файлов легко читаемы
, обычно есть некоторые файлы, у которых есть их собственный формат (пример:
Git "Packfiles") и следовательно это "непрозрачные blob",
которые не являются удобочитаемыми или перезаписываемыми без
специализированных инструментов. Также намного менее удобно переместить груду
файлов от одного места в другое, чем переместить единственный файл. И трудно
превратить документ из груды файлов в почтовое приложение, например.
Наконец, формат груды файлов ломает "метафору документа": нет
никакого файла, который пользователь может указать как "документ".
Обернутые форматы груды файлов. Некоторые приложения применяют
груду файлов, которая заключена в капсулу единственного файла, обычно это
архив ZIP. EPUB, ODT и ODP примеры этого подхода. Книга EPUB действительно
просто архив ZIP, который содержит различные файлы XHTML для текста книжных
глав, изображений GIF и JPEG для произведений искусства и специализированного
файла каталога, который говорит устройству чтения электронных книг, как XML и
файлы изображений совмещаются.
Документы OpenOffice (ODT и ODP) являются также архивами ZIP, содержащими XML
и изображения, которые представляют их содержание, а также файлы
"каталога", которые показывают взаимосвязи
между составными частями.
Обернутый формат груды файлов это компромисс между своим
форматом файла и чистым форматом груды файлов.
Обернутый формат груды файлов не непрозрачный blob
в том же самом смысле, как свой формат, так как к составным частям можно все
еще получить доступ, используя любой архиватор ZIP, но формат не совсем так
же доступен как чистый формат груды файлов, потому что архиватор ZIP нужен
и нельзя обычно использовать инструменты командной строки вроде "find"
на файловой иерархии без распаковки архива. С другой стороны, обернутый
формат груды файлов действительно сохраняет метафору документа, помещая все
содержание в файл на диске. И потому что это сжато, обернутый формат груды
файлов имеет тенденцию быть более компактным.
Как со своими форматами файлов, но в отличие от чистой груды файлов,
обернутый формат груды файлов не столь легко отредактировать, так как обычно
весь файл должен быть переписан, чтобы изменить любую составную часть. Цель этого документа состоит в том, чтобы спорить в пользу четвертой новой
категории формата файла приложения: файл базы данных SQLite.
Любое состояние приложения, которое может быть сохранено в груде файлов,
может также быть записано в базе данных SQLite с простой
схемой ключа/значения:
Но база данных SQLite не ограничивается простой структурой
ключа/значения, как база данных груды файлов. У базы данных SQLite могут быть
десятки, сотни или тысячи различных таблиц с десятками или сотнями полей
с различными типами данных и ограничениями, все с перекрестными ссылками друг
на друга, автоматически внесенными в указатель для быстрого поиска, причем
все это сохранено эффективно и сжато в файле.
И вся эта структура кратко зарегистрирована для людей схемой SQL.
Другими словами, база данных SQLite может сделать все, что груда файлов
или обернутый формат груды файлов могут сделать, плюс намного больше и с
большей ясностью. База данных SQLite это более универсальный контейнер, чем
файловая система ключа/значения или архив ZIP. Для подробного примера см.
здесь.
Сила базы данных SQLite, в теории, могла быть достигнута, используя
свой формат файла. Но любой такой формат файла, который так выразителен, как
реляционная база данных, вероятно, потребовал бы огромной спецификации
дизайна и много десятков или сотни тысяч строк кода. И конечным результатом
был бы "непрозрачный blob", который недоступен
без специализированных инструментов.
Следовательно, по сравнению с другими подходами, у использования базы
данных SQLite как формата файла приложения есть востребованные преимущества.
Вот несколько из этих преимуществ: Упрощенная разработка приложений.
Никакой новый код не нужен для чтения или написания файла приложения. Нужно
просто скомпоновать с библиотекой SQLite или включить
единственный файл "sqlite3.c"
с остальной частью прикладного C-кода, и SQLite будет заботиться
обо всем файловом I/O приложения. Это может уменьшить размер кода приложения
на много тысяч строк с соответствующей экономией в развитии и
затратах на обслуживание.
SQLite одна из библиотек программного обеспечения, которыми
наиболее часто пользуются в мире.
Есть буквально десятки миллиардов файлов базы данных SQLite в использовании
ежедневно. SQLite тщательно проверен
и доказан надежным. Это не компонент, которому нужны много настройки или
отладки, позволяя разработчикам остаться сосредоточенными
на прикладной логике.
Документы единственного файла.
БД SQLite содержится в единственном файле, который может быть легко
скопирован. Метафора "документа" сохранена.
У SQLite нет требований обозначения файла, таким образом приложение может
использовать любой суффикс файла.
Файлы базы данных SQLite содержат 4-байтовый
Application ID
в своих заголовках, который может устанавливаться в определенное значение
приложением, а затем затем использоваться, чтобы определить "тип"
документа для утилит, таких как
file(1), далее увеличивая метафору документа.
Язык запросов высокого уровня.
SQLite это полный механизм реляционной базы данных, это означает, что
приложение может получить доступ через высокоуровневые запросы.
Разработчики приложений не должны проводить время, думая о том,
"как" получить информацию, в которой они нуждаются, из документа.
Разработчики пишут SQL, который выражает, "какая" информация им
нужна, и позволяет ядру базы данных выяснить, как лучше всего получить то
содержание. Это помогает разработчикам действовать.
Формат груды файлов может быть рассмотрен как база данных ключа/значения.
База данных ключа/значения не лучше, чем никакая база данных вообще. Но без
транзакций, индексов или языка запросов высокого уровня или надлежащей схемы,
это намного более подвержено ошибкам, чем реляционная база данных.
Доступное содержание.
Информация в файле базы данных SQLite является доступной с использованием
обычных инструментов командной строки с открытым исходным кодом, которые
устанавливаются по умолчанию на системах Mac и Linux и есть в свободном
доступе как отдельный EXE-файл на Windows. В отличие от своих форматов
файлов, специализированные программы не требуются, чтобы читать или писать
содержание в базе данных SQLite. Файл базы данных SQLite не непрозрачный
blob. Верно, что инструменты командной строки, такие как текстовые редакторы,
"grep" или "awk", бесполезны на базе данных SQLite, но язык SQL-запроса это
намного более сильный и удобный способ для исследования содержания, таким
образом, неспособность использовать "grep" и "awk"
не рассматривается как потеря.
БД SQLite это четко определенный и хорошо
описанный формат файла, который пребывает в широком употреблении
буквально миллионами приложений, обратно совместим с его началом в 2004 и
обещает продолжать быть совместимым.
Долговечность файлов базы данных SQLite особенно важна для сделанных на заказ
приложений, так как она позволяет содержанию документа быть доступным
в будущем, еще долго после того, как все следы исходного приложения потеряны.
Данные живут дольше, чем код. Базы данных SQLite
рекомендуются US Library of Congress
как формат хранения для долгосрочного сохранения цифрового контента.
Кросс-платформенный.
Файлы базы данных SQLite портативны
между 32-битными и 64-битными машинами и между архитектурой с прямым порядком
байтов и с обратным порядком байтов и между любым из различных вариантов
Windows и Unix-систем. Приложение, используя формат файла приложения SQLite,
может хранить двоичные числовые данные, не имея необходимости волноваться о
порядке байтов целых чисел или чисел с плавающей точкой.
Текстовое содержание может быть прочитано или написано как UTF-8, UTF-16LE
или UTF-16BE, SQLite автоматически выполнят любые необходимые
переводы на лету.
Атомные транзакции.
Записи в БД SQLite атомны.
Они происходят полностью или нет, даже во время системных сбоев или перебоев
в питании. Таким образом, нет никакой опасности испортить документ просто
потому, что отключилось питание.
SQLite транзакционный, означая, что многократные изменения могут
группироваться таким образом, что все или ни одно из них происходят, и так,
чтобы изменения могли быть отменены до прежнего уровня, если проблема найдена
до передачи. Это позволяет внести изменение с проверками на
непротиворечивость на получающихся данных до передачи изменений на диск.
Fossil DVCS
использует это, чтобы проверить, что никакая история хранилища не была
потеряна до каждого изменения.
Возрастающие и непрерывные обновления.
При записи файла базы данных SQLite только те части файла, которые на самом
деле изменяются, записаны на диск. Это заставляет запись
произойти быстрее и экономит изнашивание SSD. Это огромное преимущество перед
другими форматами файлов, которые обычно требуют переписывания всего
документа, чтобы изменить единственный байт.
Чистые форматы груды файлов могут также сделать инкрементные обновления в
некоторой степени, хотя степень детализации
обычно больше с грудой файлов (единственный файл), чем с
SQLite (единственная страница).
SQLite также поддерживает непрерывное обновление. Вместо того, чтобы
собрать изменения в памяти и затем написать их на диск только при действии
File/Save, изменения могут быть написаны когда они происходят.
Это избегает потери работы при сбое. Автоматический
стек undo/redo, управляемый триггерами,
может быть сохранен в базе данных на диске, определяя что undo/redo
может пройти через границы сессии.
Легко расширяемый.
Когда приложение растет, новые опции могут быть добавлены к формату файла
приложения SQLite, просто добавив новые таблицы
к схеме или добавив новые колонки к существующим таблицам.
Добавление колонок или таблиц не изменяет значение предшествующих запросов,
таким образом, значение устаревших колонок и таблиц сохранено, а значит и
обратная совместимость сохраняется.
Возможно расширить форматы груды файлов также, конечно, но выполнение
этого часто намного более трудно. Если индексы добавляются, то весь код
приложения, который изменяет соответствующие таблицы, должен быть изменен,
чтобы сохранять те индексы актуальными. Если колонки добавляются, то весь код
приложения, который получает доступ к соответствующей таблице, должен быть
изменен, чтобы принять во внимание новые колонки.
Работа.Во многих случаях формат файла приложения SQLite будет
быстрее, чем формат груды файлов.
В дополнение к тому, чтобы быть быстрее, SQLite может часто существенно
улучшить время запуска, потому что вместо того, чтобы иметь необходимость
читать и разбирать весь документ в памяти, приложение может сделать запросы,
чтобы извлечь только информацию, необходимую для начального экрана. В то
время, как приложение прогрессирует, оно должно загрузить ровно столько
материала, сколько необходимо, чтобы подтянуть следующий экран, и может
отказаться от информации от предшествующих экранов,
которая больше не используется.
Это помогает держать объем потребляемой памяти под контролем.
Формат груды файлов может быть прочитан с приращением точно так же, как
SQLite. Но многие разработчики удивлены, узнав, что SQLite может прочитать и
написать меньшие BLOB (меньше, чем приблизительно 100KB)
от его базы данных быстрее, чем те же самые blob
могут быть прочитаны или написаны как отдельные файлы от файловой системы.
См. здесь и
здесь
для получения дополнительной информации. Издержки связаны с работой
механизма реляционной базы данных, однако не нужно предполагать, что I/O
файла прямого доступа быстрее, чем I/O базы данных 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, начиная с имен и формата для отдельных файлов, который все
еще должен быть описан.
Это не тривиальный пункт. Ясный, краткий и легко понятный формат файла
является ключевым для любого проектирования приложений.
Схема базы данных SQL почти всегда делает намного лучше работу по
определению и организации таблиц и структур данных и их отношений. И наличие
ясного, краткого и четко определенного представления почти всегда приводит к
приложению, которое работает лучше, имеет меньше проблем и его
легче развивать и поддержать. SQLite не идеальный формат файла приложения для каждой ситуации.
Но во многих случаях, SQLite намного лучший выбор, чем любой другой.
SQLite это высокоуровневый, стабильный, надежный, кросс-платформенный, широко
развернутый, расширяемый, производительный, доступный, параллельный формат
файла. Это заслуживает вашего рассмотрения как стандартный формат файла на
вашем следующем проектировании приложения.
Small. Fast. Reliable.
Choose any three.
SQLite как формат файла приложения
Резюме
Что такое формат файла приложения?
SQLite как формат файла приложения
Если содержание сжато, то такая база данных
архив SQLite имеет
тот же самый размер (+/-1%), как
эквивалентный архив ZIP, и это имеет преимущество
обновления отдельных "файлов", не переписывая весь документ.
CREATE TABLE files(filename TEXT PRIMARY KEY, content BLOB);
Заключение