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 ()
Ответ на: комментарий от Legioner

Можно, но только это не то, для чего они предназначены, т.е. будут проблемы. Например, SQLite может создать БД в памяти. А для Postgres нужно ФС монтировать в память — права админа нужны. И таких мелочей до кучи.

anonymous
()

Я всё больше смотрю в сторону Firebird для встраиваемых БД для своих pet-проектов.

В SQLite не хватает строгой типизации и многопоточности. Однако, Firebird менее распространён и чаще всего при работе со сторонними библотеками и программами есть обёртки и connection-драйвера для SQLite, но не для Firebird.

Pravorskyi ★★★
()

добавлена возможность применения выражения «FILTER» с агрегатными функциями

Чем это отличается от

case when CONDITION then VALUE else null end
?

No ★★
()

интересно, почему дропнул большой брат в fuchsia в этом году, свое что-то пишет?

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

ну у них там есть какая-то поделка (key-value db) брата индуса из гуглоинженеров, возможно не нуждаются или вернутся позже. Откуда вообще инфа что дропнули?

abcq ★★
()

Как почитаешь комментарии, так аж взрываешься.

IMHO PostreSQL лучше.

Как можно это сравнивать? Если тебе нужна встроенная БД из одного файла, будешь на мобилку постгрес тянуть?

Это гениальное изобретение, если нужна db из одного файла, на мобилках, планшетах, для вебморды, если не нужно тащить MySQL.

Но блин, это так трудно понять!

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

Знакомые пестни слышаю я...

А оно нужно?

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

Нужно. Я не одобряю изгибы позвоночника авторов, как бы говорящих «это легко жмулировать через left join».

Если легко эмулировать - добавьте соответствующую легкую функцию.

Столько лет прошло.

malbolge ★★
()
Ответ на: Дети от malbolge

Утверждаете, что уже 100 лет плачете о ненужном RIGHT JOIN в SQLite?

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

Девочки, не ссорьтесь. // Disclaimer: у Legioner на аватарке девочка; аноним шифруется, так что имею право предположить что угодно. :)

У SQLite очень существенное ограничение: нет параллельной записи. Плюс если параллельные чтения идут непрерывно (очередное начинается прежде чем закончились предыдущие), плюс есть пишущий поток, то write-ahead log разрастается неограниченно — ему нужен зазор между чтениями чтобы вмержить журнал в основной файл; впрочем, этот зазор можно и вручную обеспечить внешним по отношению к SQLite кодом.

По ощущениям, несмотря на вышеописанные ограничения, сабж вполне применим и для серверных приложений — где-то между всемогутером PostgreSQL и убожеством полу-недо-транзакционных embedded nosql. Как-никак обнуление межсерверных и даже межпроцессных задержек. Но сценарии использования прорабатывать придётся тщательнее.

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

1. Зачем делать встраиваемый SQL-сервер внешним, увеличивая latency?

2. А вот если бы кто-нибудь рассказал мне, как ембеддить постгрес-сервер, цены б ему не было. С год назад пытался гуглить — хрен. (Хотя есть ли смысл ембеддить такую зверюгу, и не лучше ли поискать решения попроще — отдельный вопрос.)

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

Не обращай внимания. Человек скор таким дебильным способом зарабатывает.

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

Я могу

А вот если бы кто-нибудь рассказал мне, как ембеддить постгрес-сервер,

Почти так же как и Firebird :)

Короткий ответ - никак.

Длинный ответ: зато обе вышеперечисленных достаточно легко поддаются локальной user-level настройке и запуску для одного отдельно взятого приложения. Назвать это embed нельзя, скорее local server получается, однако это хотя бы реализуется без бубна, приседаний, и, сцуко, работает. Для Firebird под маздайку по крайней мере в ветке 2.x собиралась еще отдельная DLLка - типа голый однопользовательский движок, но по факту все равно тянул ресурсы и зависимости (насколько помню процiдурку развертывания), потому лично для себя было решено не выделываться :)

Особый лулз по теме доставляет заголовок топика: SQLite это уже оказывается целая СУБД

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

Дружище, копай в сторону firebird, он как раз есть и в режиме embedded, причем по возможностям не сильно отстает от postgresql

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

Тем же, чем марокканский мандарин лучше челябинского симфонического оркестра

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

made my day

Это гениальное изобретение, если нужна db из одного файла, на мобилках, планшетах, для вебморды, если не нужно тащить MySQL.

Это гениальное изобретение, если нужна db из одного файла

db из одного файла

Firebird, SQLServer - навскидку. И не нужно тащить MySQL.

malbolge ★★
()
Ответ на: made my day от malbolge

При чем здесь MySQL?

fman2
()
Ответ на: Я могу от malbolge

Назвать это embed нельзя, скорее local server получается, однако это хотя бы реализуется без бубна, приседаний, и, сцуко, работает.

Ну это-то не новость. Постгрес действительно крайне неприхотлив в этом смысле, и вообще я его люблю. :) (Чччорт, не в той новости отписался.) Но перфекционист требовал спросить. :)

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

У SQLite очень существенное ограничение: нет параллельной записи.

Т.е. он хуже PostgreSQL.

1. Зачем делать встраиваемый SQL-сервер внешним, увеличивая latency?

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

Хотя есть ли смысл ембеддить такую зверюгу

А есть конкретные цифры, показывающие, что это таки зверюга? В чём там звериность выражается? Размер на диске, используемая память? На моём линуксе бинарник постгреса 7 мегабайтов, конечно многовато, но сколько из этого можно вырезать, если бы кто-то озадачился?

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: И да от malbolge

Чем оно лучше DQlite?

Добавочка.

Чем оно лучше DBF?

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

Плавали, знаем. Его предок Interbase 5 помнится был моим первым SQL-сервером, и доки его я проштудировал от корки до корки, и SQL полюбил благодаря ему, и много подвигов на нём насовершал. Но:

(1) firebird разве не на паскале? а линковать его как? тем более в лялихе.

(2) про него годами циркулировали слухи, что на больших объёмах баз он тупо падуч;

(3) про фичастость (в т.ч. скорость) на уровне постгреса, уж извините, нифига не верю.

UPD. Хотя констрейнты с подзапросами IB5 умел, а постгрес - НЯЗ нет; но это единственное что какое-то время после ухода с него вгоняло меня в ностальгию; и насколько те констрейнты были математически корректны и эффективны — поди теперь узнай.

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

(1) firebird разве не на паскале? а линковать его как? в тем более в лялихе.

При Царе Горохе был на Pascal.

(2) про него годами циркулировали слухи, что на больших объёмах баз он тупо падуч;

У кого «кривые руки» - ВСЕ БАЗЫ «ПАДУЧИЕ»

(3) про фичастость (в т.ч. скорость) на уровне постгреса, уж извините, нифига не верю.

Может быть и так.
См. пункт (2).

ИМХНО что лучше суп или борщ?

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

У кого «кривые руки» - ВСЕ БАЗЫ «ПАДУЧИЕ»

Вот так, дамы и господа, выглядит непреднамеренная, но очень эффективная антиреклама вещи от её фанатиков.

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

Ответы были не в защиту Firebird или какой-либо иной СУБД.
Не являюсь фанатом /ни баз, ни языков программирования, .../.
Фанатизм - болезнь.

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

1) Нет, он на с++ сейчас, вроде как его предок интербейс был на паскале, а когда отпочковались - переписали

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

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

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

М-да.
Типично для форумов.
Говоришь «белое», а трактуют как «серое», а то и «черное».

Владимир

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

а другой товарищ простейшим декартовым произведением

А постгрес кажется 8-й в одном запросе упорно делал HashJoin и вылетал по памяти, и хрен как его вылечишь кроме запрета HashJoin-ов вообще (что-то типа «set enable_hashjoin to 'off'» для текущего connection), т.к. хинты в запросы эти гады добавлять не собираются принципиально: нефиг мол в наш распрекрасный оптимизатор своими грязными руками лезть. Вот это кстати большая к ним претензия.

Тем не менее, про падучесть постгреса на больших базах слухи не гуляли.

Так что явный аутсайдер здесь мускуль, коим всегда он и был, но от этого его никто почему-то не ругает.

Гыгы. Ругают, ругают. :) Вернее, раньше ругал — и всего моего словарного запаса не хватало, но слава богу давно уже с ним не сталкивался.

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

Короче пофиг на firebird в любом случае, хотя бы из соображений распространённости: сколько народу юзает постгрес, да и сабж тоже — и где этот firebird. Случись чего — и спросить не с кого.

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

Ну как бы процент линупсов на декстопах тоже невелик)))

Касаемо падучести - падает все, главное - правильно и сильно расшатать. А касаемо подсказок (хинтов) оптимизатору, я не уверен, что они вообще где-либо кроме оракла реализованы вменяемо (в мс и сайбейс они убоги и практически бесполезны, в пг они все же есть в виде отдельного стороннего модуля, а в мускуле они есть в малом количестве для галочки, что они есть), причем даже сам оракл часть подсказок может и проигнорировать. Я уж не говорю про баг, где оракл начинает полностью игнорировать условие where. А спрашиват ьв любом случае не с кого, здесь все AS IS (грузинское народное блюдо - жричедали), если ты не платишь за ынтерпрайзную лицензию

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

У форумов фирменное блюдо - ЖРИ ЧО НАПИСАЛИ!

anonymous
()

на удивление полезная штуковина

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

Т.е. он хуже PostgreSQL.

С точки зрения общей крутизны - безусловно, естественно и неизбежно.

А есть конкретные цифры, показывающие, что это таки зверюга?

Нету. :)

В чём там звериность выражается? Размер на диске, используемая память?

В общей крутизне, и в развесистой запутанности структуры data-каталога.

На моём линуксе бинарник постгреса 7 мегабайтов, конечно многовато, но сколько из этого можно вырезать, если бы кто-то озадачился?

7 метров - вполне терпимо, для такой-то зверюги. :) // Чёт вспомнилось: Нифига себе подарочек, такая дура! - Это не дура, это лошадь! :)

Насчёт раздумий про вырезание или там прочие модуляризации (например, репликацию в отдельную опциональную либу) — не слышал, и не факт что возможно: репликация становится клиентом или плагином по отношению к ядру, а вдруг там всё настолько взаимосвязано ради оптимизаций, что её без потерь эффективности не выкинуть.

dimgel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.