Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

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

3.1 Начальное состояние

Состояние системы, когда соединение с БД только что было поднято, поверхностно изображено на рисунке справа. Справа показана информация, которая хранится на энерго-независимом носителе. Каждый прямоугольник — это сектор. Синий цвет говорит о том, что этот сектор содержит оригинальные данные. Посередине изображён дисковый кеш операционной системы. В самом начале нашего примера кеш холодный, это изображено белым цветом. На левой части рисунка — содержимое оперативной памяти процесса, который использует SQLite. Соединение с БД только что было открыто, и никакой информации прочитано не было.

Всем доброго времени суток. Хотелось бы поделиться интересным, на мой взгляд, опытом работы с SQLite.

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

Недавно я столкнулся с задачей оптимизации запроса к Sqlite в моем iOS приложении.
Задача заключалась в следующем. Имелся список документов (PDF файлов), словарь (список слов), ну и связь документов и слов из словаря (вхождение слов в документ). Необходимо было реализовать поиск и вывести список документов в которых есть введенное слово.

Структура базы имела следующий вид:

Во время недавней оптимизации запросов в базу данных наткнулся на описание работы SQLite с rowid. Если вкратце: в каждой таблице есть int64 столбец rowid, значение которого является уникальным для каждой записи в таблице. Посмотреть значение можно по имени «rowid» и в запросе * оно не показывается.

Записи хранятся как B-дерево по rowid. И это делает очень быстрым поиск и выборку по rowid. В два раза быстрее чем по primary key или по индексированному полю. Как я понял, поиск по индексированному столбцу — это поиск по B-дереву, в результате которого мы находим rowid. И уже имея rowid — ищем нужную запись.

Напрашивается очевидный вопрос: как сделать чтобы rowid и наш PRIMARY KEY совпадали?

Прочитав новость об уязвимости в Skype, позволяющей угнать любой аккаунт, в процессе чтения комментариев и постов по теме наткнулся на новую для себя информацию: оказывается, начиная с версии 4.* Skype хранит информацию о пользователе в базе sqlite. Это и навело меня на мысль о том, что информацию из базы можно легко и непринужденно получить.

Здравствуйте!

Прежде всего, хотелось бы отметить 2 момента:
— данная статья описывает алгоритм работы, а не как оптимизировать конкретные SQL-запросы;
— описываемый в статье подход не актуален для «производительного» железа, речь пойдет о том, как удалось повысить «отзывчивость» интерфейса приложения интенсивно работающего с БД на бюджетных смартфонах под управлением Android;

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

В целом статья получилось больше похожей на инструкцию по установке и работе SQL Lite.

В статье будет описано
Установка расширения для сутдии.
Добавление SQLite в проект
Добавление провайдера sqlite-net
Работа с БД через linq провайдер (в стиле LinqToSql, EF)
Работа с БД через SQL запросы (в стиле ADO.NET)

Первая часть — вводная.
Вторая часть — быстрый старт.
Третья часть — особенности.

Несмотря на то, что эта тема затрагивалась на Хабре и раньше, некоторые ключевые вещи не прозвучали. В этой статье делается попытка «закрыть тему». Замечания по дополнению/исправлению приветствуются.

Первая часть — вводная.
Вторая часть — быстрый старт.

Третья часть — тонкости и особенности.

Часть 1
Часть 3

В этой части будут затронуты непростые вопросы использования SQLite через работу с его программным интерфейсом (API).

Решил все-таки написать статью про SQLite, в которой хочу обобщить свой 3-х летний опыт использования этой БД под Windows. Вижу, что тема популярная, но информации мало.

Часть 2
Часть 3

Небольшая вводная.

Эта статья не для начинающих программистов.
Она не является учебником по SQL.
Она не агитирует использовать SQLite.
Она не агитирует не использовать SQLite.
Статья написана в виде вопросов от гипотетического новичка в SQLite и ответов на них (поскольку информации очень много и так хоть немного проще ее структурировать).

В предыдущей статье мы решили проблему некорректного использования SQLite week based calendar, написав свое расширение для этой СУБД.

Наш расчет сошелся, однако скорость его работы оставляла желать лучшего. Обработка таблицы, содержащей всего лишь 2500 записей занимала около 6 секунд. В то время как запросы, использующие strftime() исполнялись за десятые доли секунды.

Учим  SQLite работать с локализированным календарем

Часть1 — Английская версия, Часть2



Недавно мне довелось портировать (точнее, переписывать) под iOS приложение для анализа посещаемости сайта. Поскольку данные подходили под реляционную модель, мы решили использовать SQLite. Насколько я знаю, других реляционных СУБД под iOS просто нет.

Долго ли, коротко ли… Пришло время подсчитать понедельный КПД для определенного диапазона дат.

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

Alon Zakai (создатель Emscripten) продолжает действовать: на сей раз он выпустил скрипт SQL.js — итог перевода библиотеки SQLite на JavaScript при помощи его собственного средства Emscripten. Демонстрационная страница показывает скрипт в деле, и если вы взглянете на исходники, то увидите, каким простым Закай устроил использование этого средства, им скомпилированного:

var db = SQL.open();
var data = db.exec(command);

Здравствуйте. В этой статье я опишу процесс создания простейшего приложения для iOS и внедрение в него используемого мной метода для обеспечения корректной работы с русским (и не только) языком таких SQLite-конструкций, как UPPER/LOWER, LIKE или ORDER BY.

Описанный метод использовался при разработке в XCode 4.2 под управлением OS X Lion 10.7.2.

Ниже очень подробная инструкция с картинками.

“Think of SQLite not as a replacement for Oracle but as a replacement for fopen()”
— About SQLite

А также, скорее всего, под Android, BlackBerry и в сэнд-боксе браузеров для веб-приложений, но я не проверял.

Почему может быть нужно работать с SQLite напрямую?

Любой опытный iOS девелопер тут же упрекнёт меня за использование SQLite напрямую (вернее не напрямую, а через FmDb, но это почти всё равно что напрямую). Он скажет, что нужно использовать CoreData, т.к. оно много всяких ништяков делает автоматически, типа Undo и Redo. И в нём можно рисовать красивые схемки, которые потом приятно показывать заказчику. А в андроиде, например, есть OrmLite.

И я соглашусь – но до той поры, пока у вас база не перевалила, скажем, за 10 таблиц по 500,000 записей в каждой. А если таблиц 52, и есть особо жирные таблицы по миллиону и больше? И базу нужно синхронизировать с сервером через третий формат, к тому же заказчику критично, будет синхронизация длиться час или пять? Если вы встречали задачи такого объёма, добро пожаловать под кат! Если не встречали – то тоже, ведь никто не застрахован от проектов с большими данными, пускай даже таких мобильных и меньше.

В данной статье я хочу поделиться опытом интеграции расширения для стемминга в код SQLite. Все действия выполнялись в ОС Ubuntu 11.10.

Проблема

В fts3 SQLite есть простой стеммер, реализующий алгоритм стемминга Портера, но для русских слов реализации нет. Т.е. MATCH по слову 'гостиницы' не найдёт записи, содержащие слово 'гостиница' и т.д.

Подготовка к компиляции

Что понадобится

• исходники sqlite3 с репозитория;
• наш стеммер на языке C (см. далее);
• опционально библиотека readline (libreadline), если нужна история вводимых команд для консольного клиента.

Добрый день.

Ниже пойдет речь о том, как использовать SQLite в Qt. Автор постарался как можно подробнее рассматривать программирование баз данных в Qt.

Об этих двух замечательных продуктах можно прочитать следуя приведенным выше ссылкам, а мы будем конкретно рассматривать программирование БД в Qt, в частности, на примере SQLite. Скажу только, что SQLite несколько отличается от «обычных» баз данных, таких как MySQL тем, что «не обладает» клиент-серверной архитектурой. То есть движок БД не является отдельно работающим процессом, с которым взаимодействует программа. SQLite представляет собой библиотеку, с которой компонуется ваша программа и, таким образом, движок становится составной частью программы. То есть представьте вы решили сохранять все данные, с которыми «сталкивается» ваша программа в обычный файл. В один прекрасный день вы решаете сохранять данные в файле, но организовав это с «реляционной» точки зрения. После этого вы поняли, что новая структура файла должна «распознаваться особым образом». С этого, как минимум, следует, что вам нужно предоставить некоторый API, обеспечивающий связь между этим файлом данных с приложением. В общем, следуя логической постановке приведенного сценария у вас рождается система БД, не требующая сервера БД и собственно, клиента. Получается достаточно быстрая по сравнению с «клиент-серверной» БД система, и сама программа упрощается.

Здравствуй, дорогой читатель!
В этой статье я хочу затронуть проблему хранения кириллических данных в SQLite, попробовать разобраться с Android NDK, и вообще зажить прекрасной жизнью! Однако, с этого момента, считаю важными первые два пункта. О них и поговорим.

Известная проблема SQLite состоит в том, что он не любит никаких символов, кроме латинских, поэтому выполняется такое [1]:
SELECT "ы" LIKE "Ы";
0
SELECT "s" LIKE "S";
1

Такая проблема актуальна для наших широт, и может быть решена пользовательскими функциями.
Но Android не поддерживает функций, поэтому создаются костыли.