Стартуем с SQLite3 – Основные команды. Так можно вообще не задавать тип столбца

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

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

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

    Что такое SQLite?
    SQLite - это встраиваемая кроссплатформенная БД, которая поддерживает достаточно полный набор команд SQL и доступна в исходных кодах (на языке C).

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

    Сайт (с прекрасной документацией на английском): http://sqlite.org

    Текущая версия: 3.7.13

    SQLite можно скомпилировать самому, но я скачиваю ее уже скомпилированную в виде Windows DLL.

    Для собственной сборки обычно скачивают т.н. «amalgamation» ,
    т.е. исходники SQLite в виде единого файла на языке C + sqlite3.h.

    Чтобы уменьшить размер кода SQlite, выкинув ненужные ништяки, используются всякие DEFINE.

    Насколько SQLite популярна?
    Кратко: она везде. Как минимум, на любом смартфоне.
    Насколько она надежна?
    Очень. При выпуске версии она проходит через ряд серьезнейших автоматических тестов (проводится ~ 2 млн тестов), покрытие кода тестами 100% (с августа 2009).
    А какие еще инструменты дают разработчики?
    Доступна консольная утилита для работы с базами (sqlite3.exe, «a command-line shell for accessing and modifying SQLite databases»).
    И все?
    Да, от основных разработчиков - все. Однако, другие люди пишут всякие менеджеры и пр.
    Лично я так и не нашел идеального и пользуюсь консолью.
    Что значит «достаточно полный набор SQL»?
    Как известно, в своем развитии SQL устремился в разные стороны. Крупные производители начали впихивать всякие расширения. И хотя принимаются всякие стандарты (SQL 92), в реальной жизни все крупные БД не поддерживают стандартов полностью + имеют что-то свое. Так вот, SQLite старается жить по принципу «минимальный, но полный набор». Она не поддерживает сложные штуки, но во многом соответствует SQL 92.
    И вводит некие свои особенности, которые очень удобны, но - не стандартны.
    Что конкретно в поддержке SQL может вызвать недоумение?
    Нельзя удалить или изменить столбец в таблице (ALTER TABLE DROP COLUMN…, ALTER TABLE ALTER COLUMN…).
    Есть триггеры, но не настолько мощные как у крупных RDBMS.
    Есть поддержка foreign key, но по умолчанию - она ОТКЛЮЧЕНА.
    Нет встроенной поддержки UNICODE (но ее, вообщем, нетрудно добиться).
    Нет хранимых процедур.
    А что своего хорошего или необычного?
    a) каждая запись содержит виртуальный столбец rowid, который равен 64-битному номеру (уникальному для таблицы).
    Можно объявить свой столбец INTEGER PRIMARY KEY и тогда этот столбец станет rowid (со своим именем, имя rowid все равно работает).
    При вставке записи можно указать rowid, а можно - не указывать (и система тогда вставит уникальный).
    Подробности: www.sqlite.org/autoinc.html
    b) можно без труда организовать БД в памяти (это очень удобно и чуть позже расскажу подробнее);
    c) легко переносить: по умолчанию, БД - это один файл (в кроссплатформенном формате);
    d) тип столбца не определяет тип хранимого значения в этом поле записи, то есть в любой столбец можно занести любое значение;
    e) много встроенных функций (которые можно использовать в SQL): www.sqlite.org/lang_corefunc.html;
    Не понял - что там с типом? Зачем нужен тип столбца тогда вообще?
    Тип столбца определяет как сравнивать значения (нужно же их привести к единому типу при сравнении, скажем, внутри индекса).
    Но не обязывает заносить значения именно такого типа в столбец. Нечто вроде weak typing.

    Допустим, мы объявили столбец как «A INTEGER».
    SQlite позволяет занести в этот столбец значения любого типа (999, «abc», «123», 678.525).
    Если вставляемое значение - не целое, то SQlite пытается привести его к целому.
    Т.е. строка «123» превратится в целое 123, а остальные значения запишутся «как есть».

    Так можно вообще не задавать тип столбца?
    Очень часто так и делается: CREATE TABLE foo (a,b,c,d) .
    А как с архитектурой? Сервера-то нету?
    Сервера нету, само приложение является сервером. Доступ к БД происходит через «подключения» к БД (нечто вроде хэндла файла ОС), которые мы открываем через вызов соот-й функции DLL. При открытии указывается имя файла БД. Если такого нету - он автоматически создается.
    Допустимо открывать множество подключений к одной и тоже БД (через имя файла) в одном или разных приложениях.
    Система использует механизмы блокировки доступа к файлу на уровне ОС, чтобы это все работало
    (эти механизмы обычно плохо работают на сетевых дисках, так что не рекомендуется использовать SQlite с файлом на сети).
    Изначально SQlite работал по принципу «многие читают - один пишет».
    То есть только одно соединение пишет в БД в данный момент времени. Если другие соединения попробуют тоже записать, то словят ошибку SQLITE_BUSY.
    Можно, однако, ввести таймаут операций. Тогда подключение, столкнувшись с занятостью БД, будет ждать N секунду прежде, чем отвалиться с ошибкой SQLITE_BUSY.
    И как быть?
    Либо одно подключение и все запросы через него, либо исходить из возможного таймаута и предусмотреть повтор выполнения SQL.
    Есть и еще одна возможность: не так давно появился новый вид лога SQlite: Write Ahead Log, WAL .
    Если включить для БД именно этот режим лога, то несколько подключений смогут одновременно модифицировать БД.
    Но в этом режиме БД уже занимает несколько файлов.
    Ну понятно теперь почему SQLite - ужасна, ведь у нее нет ГЛОБАЛЬНОГО КЭША?
    Действительно, все современные RDBMS немыслимы без глобального разделяемого кэша, который может хранить всякие ништяки вроде скомпилированных параметризованных запросов. Этим занят сервер, которого тут нет. Однако, в рамках одного приложения SQlite может разделять кэш между несколькими подключениями (читать тут: www.sqlite.org/sharedcache.html) и немного сэкономить память.
    А почему все жалуются, что SQLite - тормозит?
    Две причины. Первая - настройки по умолчанию. Они работают на надежность, а не на производительность.
    Вторая - непонимание механизма фиксации транзакций. По умолчанию после любой команды SQlite будет фиксировать транзакцию (то есть ожидать пока БД окажется в целостном состоянии для отключения питания). В зависимости от режима паранойи SQLite потратит на это от 50 до 300 мс (ожидая окончания записи данных на диск).
    Что делать-то? Мне нужно вставить 100 тыс записей и быстро!
    Удалить индексы, включить режим синхронизации OFF (или NORMAL), вставлять порциями по N тысяч (N - подобрать, для начала взять 5000). Перед вставкой порции сделать BEGIN TRANSACTION, после - COMMIT.
    А вот я нашел ошибку! Как рапортовать?
    Никак.

    Дело в том, что популярность SQLite страшна - она везде. Это не шутка.
    И разработчики столкнулись с валом сообщений об ошибках, которые либо были вызваны непониманием, либо являлись скрытым feature request. Они, фактически, закрыли прямой прием репортов с ошибками.
    Так что следует подписаться на список рассылки и описать там проблему и надеятся на лучшее.

    Лично у меня возникла ситуация, которую я трактовал как дефект SQLIte. Я описал это в рассылке. В следующей версии поведение SQLite было исправлено.

    Удобная утилита , чтобы поиграться с SQLite.

    Продолжение следует.

    Теги:

    • sqlite
    • sql
    • rdbms
    • базы данных
    Добавить метки

    На днях мне нужно было сделать систему для быстрого формирования данных и сохранения их в SQLite базы данных. И это всё должно было работать очень быстро. К слову сказать, что нужно было добавлять и в MySQL БД. Что касается MySQL, то здесь имеется широкий выбор средств для добавления данных:

    1. простой INSERT
    2. INSERT и множеством добавляемых значений (BULK INSERT)
    3. добавление через CSV файлы

    Самым быстрым, без сомнения, оказался вариант №3. Собственного говоря, он и так использовался в системе. К слову сказать, что этот вариант позволяет добавлять в базу до нескольких сотен тысяч / миллионов записей за считанные секунды. Конечно, здесь большую роль играет и начинка сервера, но сейчас это рассматриваться не будет.

    Как мы все прекрасно знаем, и не раз убеждались, большие возможности требуют больших ресурсов и/или дополнительного ПО для добавления взаимодействия с этой системой и накладывают дополнительные ограничения.

    В отличие от MySQL, SQLite достаточно «лёгкая» и для работы с ней нужна только одна библиотека. Файлы баз данных можно размещать где угодно, передавать. Но, добавление в базу данных можно осуществить только через просто INSERT. Это значит, что добавление через «BULK» INSERT не поддерживается. А, если в таблице имеется хотя бы один ключ (как минимум это будет первичный ключ), то добавление одной записи подразумевает и перестроение индексов. Теперь представьте, нужно добавить несколько тысяч записей за максимально короткое время. Не смотря на всю легковесность и скорость SQLite, это требует достаточно много времени.

    Выход нашёлся неожиданный (по крайней мере для меня — я не изучал все возможности этой БД) — использование транзакций. Это дало прирост скорости в 10-100 раз. Сохранение/успешное завершение транзакции выполняется быстро — фактически данные просто скидываются в файл базы данных.

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

    А теперь немного цифр:

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

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

    Стоит упомянуть, что сказав, что единственным способом добавления в SQLite базы данных является простой INSERT, я не указал на то, что это единственный вариант с использованием языка SQL.

    Есть другой вариант — аналог «LOAD DATA …» в MySQL — импортирование данных из CSV файлов. Только этот вариант позволяет добавлять данные непосредственно из среды SQLite. Другими словами, нужно сперва открыть базу данных — к примеру, вызвать из консоли.

    Import путь_к csv_файлу таблица

    Разделителем по умолчанию является символ «|».

    Для того, чтобы сменить разделитель, нужно вызвать команду:

    Separator разделитель

    В качестве разделителя нужно указать разделитель колонок, например, «,».

    Скорость добавления в этом случае превосходит скорость описанного ранее способа раз в 100. Так почему же не был использован такой способ? Дело в следующем — серверный язык программирование (в данном случае PHP), может использовать одну версию sqlite библиотеки, а в системе может быть установлена (а может и нет) другая версия. При комбинации этих двух способов взаимодействия sqlite база данных может быть недоступна для одного из вариантов — при попытка чтения будет выдана ошибка.

    Это библиотека, написанная на языке C, которая обеспечивает работу с SQL. Данный инструмент относится к Реляционным системам управления базами данных . Большинство баз данных SQL работает по схеме клиент/сервер. Возьмём к примеру MySQL . В процессе работы данные берутся с MySQL сервера, и отправляются в качестве ответа на запрос. В случае использования SQLite, данные будут браться непосредственно с диска, т.е. не будет необходимости обращаться к серверу.

    Установка

    Мы будем взаимодействовать с базой данных через интерфейс командной строки sqlite3 (CLI) в Linux. Работа с sqlite3 CLI в MAC OS и Windows осуществляется таким же образом, однако я рекомендую вам потратить 5 минут на установку виртуальной машины, чтобы не захламлять свой компьютер лишним софтом.

    Для установки sqlite3 на Linux выполняем команду:

    sudo apt-get install sqlite3 libsqlite3-dev

    В результате на вашей машине будет установлен sqlite3 . Для установки данного инструмента на других ОС следуйте инструкциям . Для запуска sqlite выполняем команду sqlite3 в консоли. Результат должен быть таким:

    Во второй строчке указана подсказка о том, что для получения справки необходимо выполнить команду.help . Давайте сделаем это. В результате мы увидим Мета Команды и их описание.

    Мета Команды

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

    Стандартные команды

    Теперь давайте пройдёмся по списку стандартных команд sqlite3, которые предназначены для взаимодействия с базой данных. Стандартные команды могут быть классифицированы по трём группам:

    • Язык описания данных DDL : команды для создания таблицы, изменения и удаления баз данных, таблиц и прочего.
  • Язык управления данными DML : позволяют пользователю манипулировать данными (добавлять/изменять/удалять).
  • Язык запросов DQL : позволяет осуществлять выборку данных.
  • Заметка : SQLite так же поддерживает и множество других команд, список которых можно найти . Поскольку данный урок предназначен для начинающих, мы ограничимся перечисленным набором команд.

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

    • Email
    • Комментарий

    Из всех этих полей только адрес сайта может быть пустым. Так же можем ввести колонку для нумерации комментриев. Назовём её post_id .

    Теперь давайте определимся с типами данных для каждой из колонок:

    Атрибут Тип данных
    post_id INTEGER
    name TEXT
    email TEXT
    website_url TEXT
    comment TEXT

    Вы сможете найти все типы данных, поддерживаемые в SQLite3.

    Так же следует отметить, в SQLite3 данные, вставляемые в колонку могут отличаться от указанного типа. В MySQL такое не пройдёт.

    Теперь давайте создадим базу данных. Если вы ещё находитесь в интерфейсе sqlite3, то наберите команду.quit для выхода. Теперь вводим:

    sqlite3 comment_section.db

    В результате, в текущем каталоге у нас появится файл comment_section.db .

    Заметка : если не указать название файла, sqlite3 создаст временную базу данных.

    Создание таблицы

    Для хранения комментариев нам необходимо создать таблицу. Назовём её comments . Выполняем команду:

    CREATE TABLE comments (post_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, email TEXT NOT NULL, website_url TEXT NULL, comment TEXT NOT NULL);

    NOT NULL обеспечит уверенность, что ячейка не будет содержать пустое значение. PRIMARY KEY и AUTOINCREMENT расширяют возможности поля post_id .

    Чтобы убедиться в том, что таблица была создана, выполняем мета команду.tables . В результате видим нашу таблицу comments .

    Заметка : Для получения структуры таблицы наберите.schema comments

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

    ВСТАВКА СТРОК

    Предположим, что нам необходим внести следующую запись:

    Name: Shivam Mamgain Email: [email protected] Website: shivammg.blogspot.com Comment: Great tutorial for beginners.

    Для вставки воспользуемся командой INSERT .

    INSERT INTO comments (name, email, website_url, comment) VALUES ("Shivam Mamgain", "[email protected]", "shivammg.blogspot.com", "Great tutorial for beginners.");

    Указывать значение для post_id не нужно т.к. оно сформируется автоматически благодаря настройке AUTOINCREMENT .

    Чтобы набить руку можете вставить ещё несколько строк.

    ВЫБОРКА

    Для выборки данных воспользуемся командой SELECT .

    SELECT post_id, name, email, website_url, comment FROM comments;

    Этот же запрос может выглядеть так:

    SELECT * FROM comments;

    В результате из таблицы будут извлечены все строки. Результат может выглядеть без разграничения по колонкам и без заголовка. Чтобы это исправить выполняем:

    Для отображения шапки введите.headers ON .

    Для отображения колонок выполните команду.mode column .

    Выполняем SELECT запрос ещё раз.

    Заметка : вид отображения можно изменить, воспользовавшись мета командой.mode .

    ОБНОВЛЕНИЕ

    Предположим, что поле email для пользователя ‘Shivam Mamgain’ необходимо изменить на ‘[email protected]’. Выполняем следующую команду:

    В результате запись будет изменена.

    Заметка : Значение в колонке name может быть не уникально, так что в результате работы команды может быть затронуто более одной строки. Для всех пользователей, где значение name = ‘Shivam Mamgain’, поле email будет изменено на ‘[email protected]’. Для изменения какой-то конкретной строки следует её отследить по полю post_id . Мы его определили как PRIMARY KEY , что обеспечивает уникальность значения.

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

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

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

    Что такое SQLite?
    SQLite - это встраиваемая кроссплатформенная БД, которая поддерживает достаточно полный набор команд SQL и доступна в исходных кодах (на языке C).

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

    Сайт (с прекрасной документацией на английском): http://sqlite.org

    Текущая версия: 3.7.13

    SQLite можно скомпилировать самому, но я скачиваю ее уже скомпилированную в виде Windows DLL.

    Для собственной сборки обычно скачивают т.н. «amalgamation» ,
    т.е. исходники SQLite в виде единого файла на языке C + sqlite3.h.

    Чтобы уменьшить размер кода SQlite, выкинув ненужные ништяки, используются всякие DEFINE.

    Насколько SQLite популярна?
    Кратко: она везде. Как минимум, на любом смартфоне.
    Насколько она надежна?
    Очень. При выпуске версии она проходит через ряд серьезнейших автоматических тестов (проводится ~ 2 млн тестов), покрытие кода тестами 100% (с августа 2009).
    А какие еще инструменты дают разработчики?
    Доступна консольная утилита для работы с базами (sqlite3.exe, «a command-line shell for accessing and modifying SQLite databases»).
    И все?
    Да, от основных разработчиков - все. Однако, другие люди пишут всякие менеджеры и пр.
    Лично я так и не нашел идеального и пользуюсь консолью.
    Что значит «достаточно полный набор SQL»?
    Как известно, в своем развитии SQL устремился в разные стороны. Крупные производители начали впихивать всякие расширения. И хотя принимаются всякие стандарты (SQL 92), в реальной жизни все крупные БД не поддерживают стандартов полностью + имеют что-то свое. Так вот, SQLite старается жить по принципу «минимальный, но полный набор». Она не поддерживает сложные штуки, но во многом соответствует SQL 92.
    И вводит некие свои особенности, которые очень удобны, но - не стандартны.
    Что конкретно в поддержке SQL может вызвать недоумение?
    Нельзя удалить или изменить столбец в таблице (ALTER TABLE DROP COLUMN…, ALTER TABLE ALTER COLUMN…).
    Есть триггеры, но не настолько мощные как у крупных RDBMS.
    Есть поддержка foreign key, но по умолчанию - она ОТКЛЮЧЕНА.
    Нет встроенной поддержки UNICODE (но ее, вообщем, нетрудно добиться).
    Нет хранимых процедур.
    А что своего хорошего или необычного?
    a) каждая запись содержит виртуальный столбец rowid, который равен 64-битному номеру (уникальному для таблицы).
    Можно объявить свой столбец INTEGER PRIMARY KEY и тогда этот столбец станет rowid (со своим именем, имя rowid все равно работает).
    При вставке записи можно указать rowid, а можно - не указывать (и система тогда вставит уникальный).
    Подробности: www.sqlite.org/autoinc.html
    b) можно без труда организовать БД в памяти (это очень удобно и чуть позже расскажу подробнее);
    c) легко переносить: по умолчанию, БД - это один файл (в кроссплатформенном формате);
    d) тип столбца не определяет тип хранимого значения в этом поле записи, то есть в любой столбец можно занести любое значение;
    e) много встроенных функций (которые можно использовать в SQL): www.sqlite.org/lang_corefunc.html;
    Не понял - что там с типом? Зачем нужен тип столбца тогда вообще?
    Тип столбца определяет как сравнивать значения (нужно же их привести к единому типу при сравнении, скажем, внутри индекса).
    Но не обязывает заносить значения именно такого типа в столбец. Нечто вроде weak typing.

    Допустим, мы объявили столбец как «A INTEGER».
    SQlite позволяет занести в этот столбец значения любого типа (999, «abc», «123», 678.525).
    Если вставляемое значение - не целое, то SQlite пытается привести его к целому.
    Т.е. строка «123» превратится в целое 123, а остальные значения запишутся «как есть».

    Так можно вообще не задавать тип столбца?
    Очень часто так и делается: CREATE TABLE foo (a,b,c,d) .
    А как с архитектурой? Сервера-то нету?
    Сервера нету, само приложение является сервером. Доступ к БД происходит через «подключения» к БД (нечто вроде хэндла файла ОС), которые мы открываем через вызов соот-й функции DLL. При открытии указывается имя файла БД. Если такого нету - он автоматически создается.
    Допустимо открывать множество подключений к одной и тоже БД (через имя файла) в одном или разных приложениях.
    Система использует механизмы блокировки доступа к файлу на уровне ОС, чтобы это все работало
    (эти механизмы обычно плохо работают на сетевых дисках, так что не рекомендуется использовать SQlite с файлом на сети).
    Изначально SQlite работал по принципу «многие читают - один пишет».
    То есть только одно соединение пишет в БД в данный момент времени. Если другие соединения попробуют тоже записать, то словят ошибку SQLITE_BUSY.
    Можно, однако, ввести таймаут операций. Тогда подключение, столкнувшись с занятостью БД, будет ждать N секунду прежде, чем отвалиться с ошибкой SQLITE_BUSY.
    И как быть?
    Либо одно подключение и все запросы через него, либо исходить из возможного таймаута и предусмотреть повтор выполнения SQL.
    Есть и еще одна возможность: не так давно появился новый вид лога SQlite: Write Ahead Log, WAL .
    Если включить для БД именно этот режим лога, то несколько подключений смогут одновременно модифицировать БД.
    Но в этом режиме БД уже занимает несколько файлов.
    Ну понятно теперь почему SQLite - ужасна, ведь у нее нет ГЛОБАЛЬНОГО КЭША?
    Действительно, все современные RDBMS немыслимы без глобального разделяемого кэша, который может хранить всякие ништяки вроде скомпилированных параметризованных запросов. Этим занят сервер, которого тут нет. Однако, в рамках одного приложения SQlite может разделять кэш между несколькими подключениями (читать тут: www.sqlite.org/sharedcache.html) и немного сэкономить память.
    А почему все жалуются, что SQLite - тормозит?
    Две причины. Первая - настройки по умолчанию. Они работают на надежность, а не на производительность.
    Вторая - непонимание механизма фиксации транзакций. По умолчанию после любой команды SQlite будет фиксировать транзакцию (то есть ожидать пока БД окажется в целостном состоянии для отключения питания). В зависимости от режима паранойи SQLite потратит на это от 50 до 300 мс (ожидая окончания записи данных на диск).
    Что делать-то? Мне нужно вставить 100 тыс записей и быстро!
    Удалить индексы, включить режим синхронизации OFF (или NORMAL), вставлять порциями по N тысяч (N - подобрать, для начала взять 5000). Перед вставкой порции сделать BEGIN TRANSACTION, после - COMMIT.
    А вот я нашел ошибку! Как рапортовать?
    Никак.

    Дело в том, что популярность SQLite страшна - она везде. Это не шутка.
    И разработчики столкнулись с валом сообщений об ошибках, которые либо были вызваны непониманием, либо являлись скрытым feature request. Они, фактически, закрыли прямой прием репортов с ошибками.
    Так что следует подписаться на список рассылки и описать там проблему и надеятся на лучшее.

    Лично у меня возникла ситуация, которую я трактовал как дефект SQLIte. Я описал это в рассылке. В следующей версии поведение SQLite было исправлено.

    Удобная утилита , чтобы поиграться с SQLite.

    Продолжение следует.

    Теги: Добавить метки