LINUX.ORG.RU

Релиз СУБД SQLite 3.30.0

 ,


0

0

Состоялся релиз СУБД SQLite 3.30.0. SQLite — компактная встраиваемая СУБД. Исходный код библиотеки передан в общественное достояние.

Что нового в версии 3.30.0:

  • добавлена возможность применения выражения «FILTER» с агрегатными функциями, что дало возможность ограничить охват данных, обрабатываемых функцией, только записями по заданному условию;
  • в блоке «ORDER BY» обеспечена поддержка флагов «NULLS FIRST» и «NULLS LAST» для определения расположения элементов со значением NULL при сортировке;
  • добавлена команда «.recover» для восстановления содержимого повреждённых файлов с БД;
  • PRAGMA index_info и PRAGMA index_xinfo расширены для предоставления информации о раскладке хранения таблиц, созданных в режиме «WITHOUT ROWID»;
  • добавлен API sqlite3_drop_modules(), для возможности запрета автоматической загрузки виртуальных таблиц;
  • активированы по-умолчанию команды PRAGMA function_list, PRAGMA module_list и PRAGMA pragma_list;
  • введён флаг SQLITE_DIRECTONLY, позволяющий запретить использование SQL-функций внутри триггеров и представлений;
  • устаревшая опция SQLITE_ENABLE_STAT3 теперь недоступна.

>>> Подробности

★★★★★

Проверено: a1batross ()

Ответ на: комментарий от olelookoe

Всё-таки гораздо лучше почитать про технические детали реализации: https://www.sqlite.org/lockingv3.html, https://www.sqlite.org/wal.html. Приведённая тобой ссылка сама по себе не даёт достаточного понимания причин, почему так а не эдак.

UPD. И ещё описания всех настроек (per-server, per-connection) пролистать, ну и API хотя бы краем глаза (тут подскажу: SQL как SQL, prepared statements есть, передаётся только через текстовые строки, т.е. подсунуть ему распарсенное AST запроса для повышения скорости нельзя).

dimgel ★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

prepared statements есть, передаётся только через текстовые строки, т.е. подсунуть ему распарсенное AST запроса для повышения скорости нельзя

Вот тут уже я не распарсил. У тебя есть prepared statements? Ты можешь его юзать стопицот мильонов раз. Один раз распарсил - юзаешь до полного удовлетворения. Не надо парсить всякий раз.

olelookoe ()
Ответ на: комментарий от olelookoe

Это понятно. Я непонятно написал, хотел перечислить prepared и AST независимо друг от дружки. Речь с AST вот о чём: (1) количество prepared statements per connection ограничено; (2) для каждого нового connection нужно их заново prepare. Вот и мечталось иметь возможность ВСЕГДА опускать фазу парсинга SQL-строки сервером, подсовывая ему сразу его внутреннее AST.

Хотя это уже блажь. Сам не пробовал, но в теории — если юзать самопальный connection pool, специально заточенный для этого дела, то наверное можно не закрывать prepared statements для часто используемых операций. С другой стороны, если prepared statement уже содержит план запроса, расчитанный на основе всякой там статистики, то хранить его бесконечно — контрпродуктивно, т.к. статистика со временем меняется. А вот если тупо AST подсовывать — вроде и норм.

dimgel ★★ ()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от dimgel

Речь с AST вот о чём: (1) количество prepared statements per connection ограничено; (2) для каждого нового connection нужно их заново prepare. Вот и мечталось иметь возможность ВСЕГДА опускать фазу парсинга SQL-строки сервером, подсовывая ему сразу его внутреннее AST.

https://www.sqlite.org/sharedcache.html ?

olelookoe ()
Ответ на: комментарий от RazrFalcon

Да пилят, вроде, потихоньку

https://github.com/FirebirdSQL/firebird/pulse/monthly

Недавно вот основным движком БД стал в LibreOffice.

В общем-то довольно неплохой движок, но каких-то особенных киллер-фич, кроме как компактности да переносимости базы, у него и нет. Поэтому ИМХО и не популярен. Ну и ещё по причине «наследия» Borland/InterBase.

SkyMaverick ()
Ответ на: комментарий от One

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

abcq ()
Ответ на: комментарий от dimgel

Так переписать-то переписали, а память осталась. Я поэтому слово и закавычил.

Сто и один раз слышал при упоминании firebird (да, я его использую) слова DELPHI, Borland, InterBase - нафиг надо.

Переубеждать, что там уже давно от этого ничего не осталось - бесполезно.

SkyMaverick ()
Ответ на: комментарий от Legioner

А почему нельзя сделать SQLite в виде клиент-сервера или встроить PostgreSQL?

Троллейбус из буханки тоже можно, но зачем?

Назначение SQLite — локальное хранилище данных с SQL-синтаксисом запросов. Прикручивать к ней целый сервер значит сделать её слишком тяжеловесной.

PostgreSQL — тот самый целый сервер. Тащить его туда, где применяют SQLite — нутыпонел.

Их, наоборот, можно сочетать. Вот у меня по работе написан целый программный комплекс, который умеет работать и в локальном, и в клиент-серверном варианте. И там как раз используются оба названных продукта. На уровне прикладного кода разницы почти нет. Только в клиент-сервере используется несколько хранимых процедур на PL/pgSQL, для локального варианта пришлось написать аналоги.

Унификацией занимается QtSql. Работает, есть не просит.

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Троллейбус из буханки тоже можно, но зачем?

А зачем плодить проекты, которые делают одно и то же?

Назначение SQLite — локальное хранилище данных с SQL-синтаксисом запросов. Прикручивать к ней целый сервер значит сделать её слишком тяжеловесной.

«Целый сервер» это несколько сотен строк кода.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

«Целый сервер» это несколько сотен строк кода.

У меня по прочтении твоих комментариев весёлое настроение. Я не хочу спорить, просто выскажу осторожное предположение, что такой сервер будет работать ненамного лучше, чем база Microsoft Access, расшаренная по сети (да-да, и такое извращение встречать приходилось).

Просто раз речь зашла про такие предположения — скачай исходники PostgreSQL да посмотри, какой код там используется для обеспечения одновременного доступа кучи пользователей к БД. Вперёд, никто не мешает.

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Как другие используют SQLite:
- 1С 8.x хранит в ней настройки;
- FAR, google, ... - хранят в ней «историю», ...;
- виртуальные таблицы можно использовать в качестве «индексированных таблиц»
с возможностью удобного поиска в них данных , ...;
- ...

При разработке прикладного кода C++, многие используют SQLite для хранения настроек, ... /см. выше/.
Поищите в каталогах google, Firefox, FAR, ... базы SQLite и поймете, что SQLite многие «не брезгуют».

Кстати когда чистите «историю» в google, то ради интереса посмотрите не остались ее следы в базах SQLite.

Шутка.
PS: Советую не посещать «вселенную SQLite» иначе из нее будет потом трудно выбраться.

Владимир

anonymous ()
Ответ на: комментарий от anonymous

Ниже приведен список баз SQLite, которые использует Chrome:

Cookies
Extension Cookies
Favicons
History
Login Data
Network Action Predictor
Origin Bound Certs
previews_opt_out.db
QuotaManager
Shortcuts
Top Sites
Web Data
Databases.db

anonymous ()
Ответ на: комментарий от dimgel

Почему? Получил подключение, породил поток. Всё API тривиально ложится на протокол. Хоть самописный, хоть JSON какой. Получил команду, вызвал функцию из API, сериализовал и вернул результат. Всё. Что тут нетривиального?

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Что тут нетривиального?

Тут - ничего. Но это не решает проблему мультиюзера. Несколько писателей пишет с применением блокировки на уровне DB - это неэффективно. Поэтому нужны блокировки на уровне таблиц, а поскольку и с этим возникают проблемы, нужны блокировки на уровне полей, етц. У пользователей могут быть или не быть права на объекты, на запись, чтение и бла-бла-бла. И это только начало.

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

olelookoe ()
Ответ на: комментарий от anonymous

Хороший tools.

https://github.com/sqlitebrowser/sqlitebrowser             Official home of the DB Browser for SQLite (DB4S) project. Previously known as "SQLite Database Browser" and "Database Browser for SQLite". Website at: 
                                                           DB Browser for SQLite (DB4S) is a high quality, visual, open source tool to create, design, and edit database files compatible with SQLite.
                                                           It is for users and developers wanting to create databases, search, and edit data. It uses a familiar spreadsheet-like interface, and you don't need to 
                                                           learn complicated SQL commands.

                                                           Controls and wizards are available for users to:
                                                           
                                                           Create and compact database files
                                                           Create, define, modify and delete tables
                                                           Create, define and delete indexes
                                                           Browse, edit, add and delete records
                                                           Search records
                                                           Import and export records as text
                                                           Import and export tables from/to CSV files
                                                           Import and export databases from/to SQL dump files
                                                           Issue SQL queries and inspect the results
                                                           Examine a log of all SQL commands issued by the application
                                                           Plot simple graphs based on table or query data
anonymous ()
Ответ на: Знакомые пестни слышаю я... от malbolge

Я не фан sqlite, но раздувать из мухи слона такое себе. right join легко эмулируется через left join, а учитывая специфику того, что sqlite встраиваемая СУБД, то тащить туда весь сахар так себе идея.

peregrine ★★★★★ ()
Ответ на: комментарий от TooPar

Не передать файл спокойно

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

не инсталлировать на девайсы особо умных

eCryptfs реализована в виде модуля ядра Linux, дополненная различными утилитами для работы с ключами. (с) Вики

olelookoe ()
Ответ на: комментарий от olelookoe

Можно ещё добавить, что transaction isolation levels — как раз про это; и что на самом деле этих уровней больше четырёх, если рассматривать детали реализаций. Версионники vs блокировочники опять же... Одни только предикатные блокировки в serializable чего стоят... Не один десяток диссертаций небось написан про эту «тривиальщину». А то и не одна сотня.

dimgel ★★ ()
Ответ на: комментарий от peregrine

+1. И вообще — не нужно! :) Лично мне вообще не помню когда последний раз right join был нужен. Структурировать запрос всегда в одной и той же манере тупо проще.

dimgel ★★ ()
Ответ на: комментарий от windows10

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

drfaust ★★★★★ ()
Ответ на: комментарий от anonymous

а сколько кода занимает PostgreSQL

До 11 версии мегабайт 10 бинарь. Сейчас больше 100 — теперь про эмбед постгри можно даже не задумываться. Но в соседней теме все отчитались, что их это не волнует

spoonbob ()
Ответ на: комментарий от drfaust

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

Наглядный пример, с которым приходится сталкиваться почти каждый день — клиент видеонаблюдения IVMS-4200. Конфиги хранятся в виде зоопарка из >20 файлов разного формата. При аварийном завершении, конфиги ломаются и следующее открытие показывает ненастроенный интерфейс без камер

Програмка мелочь в плане хранения данных. Но на практике это выливается в полную неюзабельность для постов охраны. Так что даже для банального хранения настроек очень желательно соблюдать ACID

spoonbob ()