c# — Многопоточность в Sqlite multithreading | CODE Examples [русский]

This information is obsolete. You are looking at the CVSTrac source management system display for SQLite that was replaced by Fossil on 2009-08-11. The information shown here has not been updated since that cut-over. These pages are retained for historical reference only.

I have been working on a Mac OS X project which uses SQLite. At some point I decided to test SQLite’s multithreading capabilities, in case I need it someday. I found information scattered around the SQLite group list, but nothing comprehensive. This is the main reason in writing this paper, and of course, to share it with SQLite developers.

Keep in mind, however, that I will have left things out. If you happen to discover something about multithreading that isn’t covered here, feel free to add it. Some of the references in this paper are Mac OS X related because this is the environment I’ve been working on.

Is SQLite thread-safe?

Short answer: Yes

Medium length answer:

  1. Be sure to recompile with -DTHREADSAFE=1
  2. Do not use the same database connection at the same time in more than one thread.
  3. On some operating systems, a database connection should always be used in the same thread in which it was originally created.
  4. There are a few features of SQLite that are not threadsafe. Avoid those features.

Longer answer:

The precompiled binaries for windows have traditionally been threadsafe.

The precompiled binaries for unix have not been. That might change in the future, so always check. But in the past, if you wanted a thread-safe version of SQLite for unix, you’d need to get the sources and compile it yourself.

By "threadsafe" we mean that you can use different SQLite database connections in different threads at the same time. It has never been safe to use the same database connection simultaneously in multiple threads. If you use the sqlite3_prepare() API to create prepared statements, each prepared statement is considered to be a part of the database connection from which it was derived. So you cannot run two prepared statements originating from the same database connection in different threads at the same time.

There is a bug in some Linux implementations (RedHat9 is the canonical example) that prevents fcntl() locks created by one thread from being modified in a different thread. If you are running on one of those systems, then you should always use an SQLite database connection in the same thread in which it was originally created. It is not safe to open the database in one thread and then pass the connection off to a different thread for processing.

The restriction of the previous paragraph has been relaxed somewhat as of SQLite version 3.3.1. Beginning with version 3.3.1, you should be able to move database connections from one thread to another as long as there are no locks outstanding at the time you move the thread. If you are not running on one of the systems effected by the fcntl() locking bug, then you can move your database connections at any time you want. But for portability, you probably should assume your system has the bug.

So, beginning with version 3.3.1, the common paradigm of maintaining a pool of database connections and handing them off to worker threads for processing should work fine — as long as your worker threads are careful to finalize all of their prepared statements prior to exiting. For added safety, your worker threads would do well to call sqlite3_thread_cleanup() before exiting — though this is only a precaution against latent bugs and is not strictly necessary.

If you compile SQLite with the -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1 option, then SQLite maintains a count of all outstanding memory allocations for each thread. In that case, you should only use an SQLite database connection in the same thread in which it was originally created — otherwise things will be malloc()-ed in one thread and free()-ed in another and the counts will get all out-of-whack. The -DSQLITE_ENABLE_MEMORY_MANAGEMENT feature is generally only useful for low-memory embedded devices. If you do not need it you are well advised to leave it turned off. It is turned off by default.

If you enable the shared cache feature of SQLite using the sqlite3_enable_shared_cache() API, then database connections that use the shared cache should only be used in the same thread in which they were originally created.

The PRAGMA temp_store_directory SQL statement is not thread-safe. If you need to change the directory in which SQLite is storing temporary files, do so once at program initialization and thereafter leave the setting alone.

The "localtime" modifier for the built-in date/time functions uses the localtime() C API, which is not threadsafe. The call to localtime() in SQLite is protected by a mutex, so the "localtime" modifier is safe to use as long as nothing else in your program calls localtime() independently of SQLite. Note: in Linux/GNU LIBC gmtime() shares the same global time structure used by localtime(), so your program may not be able to call gmtime() safely in a multithreaded environment with SQLite. In general if you can guarantee that your program exclusively uses the _r variants of all the POSIX date functions, you are probably okay.

Any aspect of SQLite that is not mentioned above is considered threadsafe. If you have doubts, ask on the mailing list.

SQLite multithreading settings

The setting named THREADSAFE turns multithreading on or off. It’s turned on by default in the precompiled Windows binaries and it’s off by default in the precompiled Linux binaries. Under Linux, Mac OS X and other Unix systems, you’ll have to set it manually. If you’re using Mac OS X’s Project Builder, you can easily turn on multithreading by adding -DTHREADSAFE=1 to the Other C Compiler Flags field, in the following panel:

Project:Edit active target ‘<your project>’:Settings:GCC Compiler Settings

Some messages in the SQLite group list refer to the following functions: sqliteOsEnterMutex() and sqliteOsLeaveMutex(). These functions set and clear the mutex lock, which is needed to guarantee a thread-safe environment. Under Mac OS X and Windows, the sqliteOsEnterMutex() and sqliteOsLeaveMutex() functions are already implemented in os.c.

Study case: multithreaded insert on the same database

If you’re new to SQLite, take a quick look at this tutorial.

  • Spawn two or more threads. Each one, opens the db via sqlite_open() and keeps its own copy of sqlite structure.
  • Each thread then proceeds to insert a number of records, let’s say 1000. The problem you will encounter is the following: one thread will get control over the database by setting a lock on the file. This is fine, but the rest of the threads will keep on failing for each attempted INSERTwhile the lock is active.


Test for SQLITE_BUSY, which I didn’t do originally. Here’s some pseudo-code to illustrate a solution:

while (continueTrying) { retval = sqlite_exec(db, sqlQuery, callback, 0, &msg); switch (retval) { case SQLITE_BUSY: Log("[%s] SQLITE_BUSY: sleeping fow a while…", threadName); sleep a bit… (use something like sleep(), for example) break; case SQLITE_OK: continueTrying = NO; // We’re done break; default: Log("[%s] Can’t execute \"%s\": %s\n", threadName, sqlQuery, msg); continueTrying = NO; break; } } return retval;

An alternative approach is:

  • Establish a busy handler procedure with sqlite_busy_handler(). In the busy handler wait on a monitor or condition variable or event with appropriate timeout. Give up with error after the busy handler has been called some number of times.
  • In all places where sqlite_exec() et.al. is called, signal the monitor or condition variable or event after sqlite_exec() et.al. returned. This makes other threads waiting in the busy handler runnable and finally one of them getting out of the busy condition.

An example implementation of that pattern can be found in the Java SQLite wrapper on http://www.ch-werner.de/javasqlite in the SQLite.JDBC2.JDBCConnection class.


Use transactions. I cannot stress enough how important they become to improve performance:

  1. It speeds up batched operations, regardless of whether SQLite is running in single threaded, multithreaded, or multiprocess mode.
  2. The number of collisions (or waits) that a thread suffers is reduced dramatically if we run the batched manipulation enclosed within a transaction.

Case in point: a benchmark application I’ve written for this purpose

Without transactions

2003-01-10 09:58:49.465 SQLiteThreadTest[14737] Begin multithreaded test…
2003-01-10 09:58:49.529 SQLiteThreadTest[14737] [Thread1]: starting without transaction…
2003-01-10 09:58:49.541 SQLiteThreadTest[14737] [Thread2]: starting without transaction…
2003-01-10 09:58:49.549 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:58:49.559 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:58:49.570 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…

2003-01-10 09:58:56.666 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:58:56.667 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:58:56.669 SQLiteThreadTest[14737] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:58:56.670 SQLiteThreadTest[14737] Thread Thread1 has finished: 1000 good inserts | 0 bad inserts | 470 collisions
2003-01-10 09:58:57.139 SQLiteThreadTest[14737] Thread Thread2 has finished: 1000 good inserts | 0 bad inserts | 552 collisions
2003-01-10 09:58:57.156 SQLiteThreadTest[14737] Finish multithreaded test…

With transactions

2003-01-10 09:52:38.806 SQLiteThreadTest[14714] Begin multithreaded test…
2003-01-10 09:52:38.887 SQLiteThreadTest[14714] [Thread1]: starting using a transaction…
2003-01-10 09:52:38.893 SQLiteThreadTest[14714] [Thread2]: starting using a transaction…
2003-01-10 09:52:38.894 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:52:38.895 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:52:38.898 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…

2003-01-10 09:52:39.258 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:52:39.259 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:52:39.261 SQLiteThreadTest[14714] [Thread2] SQLITE_BUSY: sleeping fow a while…
2003-01-10 09:52:39.262 SQLiteThreadTest[14714] Thread Thread1 has finished: 1000 good inserts | 0 bad inserts | 0 collisions
2003-01-10 09:52:41.445 SQLiteThreadTest[14714] Thread Thread2 has finished: 1000 good inserts | 0 bad inserts | 117 collisions
2003-01-10 09:52:41.466 SQLiteThreadTest[14714] Finish multithreaded test…


  • Without transactions: 470 + 552 = 1022 collisions in ~8 seconds
  • With transactions: 0 + 117 = 117 collisions in ~3 seconds


  • Make sure you’re compiling SQLite with -DTHREADSAFE=1.

  • Make sure that each thread opens the database file and keeps its own sqlite structure.
  • Make sure you handle the likely possibility that one or more threads collide when they access the db file at the same time: handle SQLITE_BUSY appropriately.
  • Make sure you enclose within transactions the commands that modify the database file, like INSERT, UPDATE, DELETE, and others.

Multithreading and Temporary Tables

When you use temporary tables, the main database is not locked, so, for instance, one thread can do read operations on the temporary table at the same time as another thread is doing write operations on a table in the main database. This feature can often be used to great advantage when having multithreaded access to the database. By creating a temporary table containing the results of a large query for processing, rather than processing it directly out of the main database, you greatly reduce lock contentions.

(comment) discussion about this at http://sqlite.phxsoftware.com/forums/2284/ShowThread.aspx#2284

   SQLiteStudio is a SQLite database manager with the following features:

  • Portable — no need to install or uninstall.

    Just download, unpack and run.

  • Intuitive interface,
  • Powerful, yet light and fast,
  • All SQLite3 and SQLite2 features wrapped within simple GUI,
  • Cross-platform — runs on Windows 9x/2k/XP/2003/Vista/7, Linux, MacOS X and should work on other Unixes (not tested yet).
  • Exporting to various formats (SQL statements, CSV, HTML, XML, PDF, JSON),
  • Importing data from various formats (CSV, custom text files [regular expressions]),
  • Numerous small additions, like formatting code, history of queries executed in editor windows, on-the-fly syntax checking, and more,
  • Unicode support,
  • Skinnable (interface can look native for Windows 9x/XP, KDE, GTK, Mac OS X, or draw widgets to fit for other environments, WindowMaker, etc),
  • Configurable colors, fonts and shortcuts.
  • Open source and free — Released under GPLv3 license.

How can you help?


(this operation requires address, click here to find out why)

GitHub migration

SQLiteStudio has recently migrated to GitHub. This affects the source code repository, as well as issue tracker (bugs & feature requests). This should improve colaboration with potential contributors and also make it more readable, as GitHub has well established platform for the same. All bug reports from old tracker have been migrated to GitHub.

Version 3.1.1 released!

Among tons of bugfixes, there are some new features, such as plugins supporting wxSQLite and System.Data.SQLite databases (latter one only under Windows), batch importing with import() (and its import_*() family) function, support for «Row Value» from recent SQLite 3.15.0 and others — see ChangeLog for full list of changes.

3.1.0 released!

Next major release — it brings SQLCipher plugin and support for new features from SQLite 3.9.x (indexed expressions, explicit View columns), but there is much, much more! See full changelog for details.

DbAndroid plugin 1.1.1 released

This is an update to Android plugin, which fixes some issues when connecting to the device using shell connection method.

3.0.7 released!

This release brings one major feature — when editing foreign key column values user can pick value from dropdown list with valid values for this foreign key. There’s also a new entry in context menu when clicked on foreign key cell — «go to referenced row in foreign table». There also some minor bugfixes. More details in the ChangeLog.

Archive »


Copyright 2007-2018 — SalSoft Pawel Salawa | Privacy Policy

This site uses Cookies.

I accept it, don’t show this again.

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

Конечно же, сервер должен поддерживать драйвер SQLite (также как и любой другой БД), но как правило сейчас с этим проблем нет.

SQLite позволяет привычно работать с базой через SQL, создавать таблицы, поля и т.д. В целом можно сказать, что SQLite ни в чем не уступает привычной MySQL, за исключением, пожалуй более медленной работы с «тяжелыми» sql-запросами по обновлению данных (insert и update). Но, опять же, это для высоконагруженных сайтов.

Огромным плюсом SQLite будет её легкая переносимость.

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

Для работы с базой данных в PHP лучше использовать PDO — Объекты данных PHP — это т.н. абстракция, которая предлагает единый интерфейс для работы с разными базами. В теории, используя PDO, можно переключиться на любую базу, не переделывая SQL-запросы, например с MySQL на SQLite. Меняются только параметры подключения.

Таким образом SQLite будет подключаться через PDO. Для этого ничего не требуется, поскольку сам PDO уже в составе PHP, а драйвер SQLite, как правило, также включен на серверах.

Но, прежде, чем приступать к программированию, нужно создать саму базу. Например для MySQL существует phpMyAdmin, через который можно выполнять различные операции. Для SQLite также есть похожие разработки, но я покажу, как можно это делать через браузер FireFox. Для этого потребуется только установить дополнение SQLite Manager.

Чтобы добавить это дополнение в основное меню FireFox («гамбургер»), нажмите Изменить и перетащите мышью икноку в меню.

На этом SQLite Manager установлен и можно им пользоваться.

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

Этот файл можно перемещать (и переименовывать) куда угодно, а после открывать командой меню Базы данных — Подключить базу данных.

Теперь нужно создать таблицу (или таблицы) в базе данных.

SQLite Manager автоматом создаёт служебные таблицы sqlite_XXX. Мы их не трогаем и нам они не мешают.

Таблица в БД — это то место, где хранится структурированная информация. Таблица должна иметь набор полей с заданными свойствами. Например поле может быть integer — для целых чисел, или text — для текста. Количество полей может быть произвольным и определяется только задачей вебмастера.

Пусть, например, у нас будет таблица с полями

  • id — уникальный номер (автоинкремент)
  • slug — ссылка
  • text — произвольный текст
  • hits — число просмотров

После того, как таблица создана, обратите внимание на блок «SQL-оператор создавший этот объект». В нем будет SQL-запрос, которым можно создать таблицу. Он может пригодится, если требуется создать таблицу в базе через PHP.

На вкладке «Просмотр и Поиск» можно редактировать таблицу. Создадим для примера две строчки, где поле slug будет и . Это будут две страницы: главная и сайт/contact.

Поле hits будет содержать счетчик просмотров страницы. Текст может быть любым.

Всё, база готова, теперь можно её использовать.

Поставим задачу. Пусть у нас будет простенький сайт, который будет выдавать по короткой ссылке (slug) соответствующий текст и количество просмотров.

Если мы делаем это на локальном сервере, то пусть сайт будет в каталоге sqlite. В нём подкаталог db, куда мы и скопируем наш pages.sqlite.

Роутинг мы можем сделать, как описано в предыдущей статье PHP-роутинг (Routing) для новичков. Файл

AddDefaultCharset UTF-8 Options -Indexes <IfModule mod_rewrite.c> RewriteEngine on RewriteBase /sqlite/ RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule (.*) /sqlite/index.php?$1 [QSA,L] </IfModule>

В index.php сам роутинг будет описан одной строчкой:

$page = ($p = key($_GET)) ? $p : ‘home’;

То есть будет содержать ссылку или для главной.

Дальше алгоритм будет такой:

  • подключаем базу
  • делаем в ней выборку по
  • выводим полученные данные

Я намеренно упрощаю алгоритм, чтобы не усложнять php-код.

Существуют два варианта работы с БД. Первый — это нативный php-код. Он не очень сложный, но обилие параметров немного напрягает. Поэтому второй вариант — использование дополнительных библиотек-оберток.

С ними код становится лаконичней.

Приведу код в первом варианте:

<?php $page = ($p = key($_GET)) ? $p : ‘home’; try { $pdo = new PDO(‘sqlite:db/pages.sqlite’); $pdo->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC); $sql =’SELECT * FROM pages WHERE slug=:page LIMIT 1′; $sth = $pdo->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_FWDONLY)); $sth->execute(array(‘:page’ => $page)); $rows = $sth->fetchAll(); print_r($rows); // здесь выводим данные } catch(Exception $e) { echo $e->getMessage(); } # end of file

Для второго варианта я использовал php-библиотеку с сайта labaka.ru, которую разместил в подкаталог lib.

Код :

<?php $page = ($p = key($_GET)) ? $p : ‘home’; require ‘lib/sqlite.php’; try { $db = new Db(‘db/pages.sqlite’); $row = $db->queryRow(‘SELECT * FROM pages WHERE slug=:page LIMIT 1’, array(‘:page’ => $page)); if ($row) { echo $row[’text’]; echo ‘<br>Просмотров: ‘ . $row[’hits’] . ‘<br>’; $db->update(‘pages’, array(‘hits’ => $row[’hits’] + 1), ‘id=:id’, array(‘:id’ => $row[’id’])); } } catch(Exception $e) { echo $e->getMessage(); } # end of file

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

Здесь следует отметить пару важных моментов.

В первую очередь, вся работа с PDO должна заключаться в блок . Таким способом отлавливаются сообщения об ошибках.

Данные, которые отправляются в sql-запрос должны проходить через валидацию. В PDO, когда используется предподготовка данных (PDO::prepare), выполняется принудительное экранирование параметров. Это позволяет защититься от возможных SQL-инъекций.

Когда происходит подключение базы данных SQLite, в случае отсутствия файла базы, он будет создан автоматически. На этом базируется создание базы сразу после его подключения и создание нужных таблиц первым sql-запросом (о котором я написал выше).

Еще одно замечание по SQLite. Поскольку база это файл, то его можно скачать по URL прямо через браузер. Поэтому каталог с SQLite-файлами лучше защищать через строчкой . Или же размещать выше чем основной www-каталог.

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

Вы можете скачать файлы к этой статье.

Введение в SQLite

SQLite – это библиотека, написанная на языке C, реализующая SQL механизм работы с данными, другими словами, движок баз данных.

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

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

Основные преимущества использования SQLite

Распространяется бесплатно.

Простота установки.
В PHP 5 поддержка SQLite встроена автоматически (SQLite 2.8.14).

Легкость администрирования.
А поскольку SQLite хранит данные в обычных файлах, то отпадает всякая необходимость в дополнительных средствах администрирования. Каждый пользователь имеет свои собственные базы данных (в любом количестве создаваемые самим пользователем!) и права доступа реализуются файловой системой сервера автоматически.

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

Поскольку движок базы и интерфейс к ней реализованы как единое целое, огромный преимуществом SQLite является высокая производительность – для большинства типичных задач приложение, построенное на SQLite, работает быстрее, чем при использовании MySQL, в 2-3 раза и быстрее PostgreSQL в 10-20 раз! И это притом, что объем памяти сервера, который он выделяет для SQLite, очень и очень мал.

По данным тестирования — www.hwaci.com/sw/sqlite/speed.html

Легкая переносимость между платформами, веб-серверами и приложениями.
Фалы баз данных совместимы с различными платформами (Windows, UNIX). Для переноса базы данных на веб-сервер нужно всего лишь перенести 1 файл.

Резервное копирование данных также осуществляется копированием файла базы данных.

Объектно-ориентированный интерфейс.
Еще одним не менее важным преимуществом SQLite является возможность использования мощного объектно-ориентированного интерфейса к SQLite, что позволяет строить высокоэффективные, легко расширяемые приложения.

Возможность хранить данные в базе объемом до 2 терабайт.

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

Ограничения использования SQLite

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

к базам данных   к 4GL — визуальным средам

СУБД-движок SQLite

SQLite — компактная встраиваемая реляционная база данных. Исходный код библиотеки передан в общественное достояние. В 2005 году проект получил награду Google-O’Reilly Open Source Awards.

Слово “встраиваемый” означает, что SQLite не использует парадигму клиент-сервер, то есть движок SQLite не является отдельно работающим процессом, с которым взаимодействует программа, а предоставляет библиотеку, с которой программа компонуется и движок становится составной частью программы. Таким образом, в качестве протокола обмена используются вызовы функций (API) библиотеки SQLite. Такой подход уменьшает накладные расходы, время отклика и упрощает программу. SQLite хранит всю базу данных (включая определения, таблицы, индексы и данные) в единственном стандартном файле на том компьютере, на котором исполняется программа. Простота реализации достигается за счёт того, что перед началом исполнения транзакции записи весь файл, хранящий базу данных, блокируется; ACID-функции достигаются в том числе за счёт создания файла журнала.

Несколько процессов или потоков могут одновременно без каких-либо проблем читать данные из одной базы. Запись в базу можно осуществить только в том случае, если никаких других запросов в данный момент не обслуживается; в противном случае попытка записи оканчивается неудачей, и в программу возвращается код ошибки.

Другим вариантом развития событий является автоматическое повторение попыток записи в течение заданного интервала времени.

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

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

Старые версии SQLite были спроектированы без каких-либо ограничений, единственным условием было то, чтобы база данных умещалась в памяти, в которой все вычисления производились при помощи 32-разрядных целых чисел. Это создавало определённые проблемы. Из-за того, что верхние пределы не

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


Это может быть полезным, если SQLite используется в веб-приложениях, так как уменьшенные пределы могут предотвратить DoS-атаки со стороны недоверяемых внешних клиентов.

Сама библиотека SQLite написана на C; существует большое количество привязок к другим языкам программирования, в том числе C++, Java, C#, VB.NET, Python, Perl, PHP, Tcl (средства для работы с Tcl включены в комплект поставки SQLite), Ruby, Haskell, Scheme, Smalltalk, Lua и Parser, а также ко многим другим.

Полный список существующих средств размещён на странице проекта.

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

В частности, SQLite используют:

  • Adobe Integrated Runtime — среда для запуска приложений (частично);

Добавить комментарий

Закрыть меню