Опубликован релиз SQLite 3.35, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54779
Отличная СУБД! Использую на постоянной основе в своих проектах.
Это все равно что постоянно в своих проектах применять электрон.
электрон со словом Lite разве хоть как-то коррелируется?
держу пари, у тебя никаких проектов отродясь не было
У тебя они можно подумать были
у меня были
У меня тоже были на электроне, но мне стыдно об этом говорить так открыто. Бесстыдники вы.
Пруф, или не было?
А пруф на то, что не было?)
То-то разрабы приложений практически на всех мобильных ОСях его применяют прямо или косвенно
То-то разрабы практически для всех десктопных приложений применяют электрон.
Окей анон, а что используешь ты в качестве хранилища небольшого числа параметров и настроек уровня [мобильного] приложения ?
Для андроида есть https://github.com/nhachicha/SnappyDB
На порядок быстрее и сериализация из коробки, если реляционщина не нужна.
Которая с последним коммитом в 2019 году и заархивирована на GitHub? Которая и не SQL база данных, а key-value - т.е. принципиально другая база данных. Как это вообще можно сравнивать и рекомендовать на замену?
> Которая с последним коммитом в 2019 году и заархивирована на GitHub?Это форк LevelDB гугловской, которая вполне себе свежа и акутальна.
> Как это вообще можно сравнивать и рекомендовать на замену?
Ещё как можно, если решаемая задача одинакова. На мобилках бд обычно как кэш используется, key-value хранилище для такого случая самое то.
Если решаемая задача гораздо уже полноценной SQL и это обычный кэш - да, можно. Но лучше взять что-то получше, например mmkv.
для параметров и настроек-то чем тебе key-value не угодила? Мы используем для этого sqlite не потому что нам там офигеть как нужен рекурсивный select, а потому что все доступные key-value имеют архиинтереснейшую привычку превращаться в невосстанавливаемые тыквы - с тех пор как орацл угробил единственную работающую реализацию (угу, bdb 1.83)Но и та проигрывает sqlite и в эффективности, и в удобстве использования, и в надежности.
Странные тут анонимы. Мы говорим про полноценную SQL базу данных, со всеми фичами, транзакциям, индексами и т.п. И альтернативу нужно предлагать соответствующую. Альтернатив, к сожалению, нет.А key-value БД - это другой класс задач. Гораздо более простой. К слову, в мире SQL - это фактически движки / хранилище (RocksDB, LevelDB) поверх которых и пишутся современные БД (типа YugaByte и других распределенных new SQL, много их).
Это как предлагать ассемблер вместо С.
А для чисто key-value есть и получше решения, например https://github.com/Tencent/MMKV. На нём крутится WeChat с миллиардами установок. Я, конечно, никогда не поверю что она у них "превращается в тыкву". Можно смело брать и пользовать.
> Странные тут анонимы. Мы говорим про полноценную SQL базу данныхмы тут говорили про вполне конкретную узкую задачу - "настройки программы хранить".
Для этого _могут_ пригодиться и индексы (настроек бывает много) и транзакции (когда два инстанса их пытаются поменять параллельно) и много чего еще. Но чаще всего - нафиг не надо, но проект все равно использует sqlite. Потому что - а почему, собственно, и не использовать?
Удобно отлаживать, несложно кодить, не надо свой парсер писать, а что 99% фич не используется - кому от этого плохо?Для совсем героической экономии на спичках всегда можно собрать библиотеку самому, выключив в ней все подряд.
С другой стороны - вот тебе "настройки программы":
{"version":1,"buildID":"20180621064021","locale":"en-US","visibleDefaultEngines":["google","amazondotcom","bing","ddg","twitter","wikipedia"],"metaData":{"searchDefault":"Yandex","searchDefaultHash":"ij34vUl7VxeE6/Ey8A9/RiMl3lWvWt5eHY91Y80eFOe=","visibleDefaultEngines":"amazondotcom,bing,google,twitter,wikipedia,ddg,yandex-en","visibleDefaultEnginesHash":"BrEcJNgz8eaD0IaEqozDG0Yu22kM8rh0Hp7eutPIB7s=","searchDefaultExpir":1600861550282,"current":"DuckDuckGo","hash":"X4VB1R18brdeVPy69cwVo050dpRSulpLpJEDxBo0rzs="},"engines":[{"_name":"Google","_shortName":"google","_loadPath":"jar:[app]/omni.ja!browser/google.xml","description":"Google Search","__searchForm":null,"_iconURL":"data:image/x-icon;base64,AAAцкий пц на две страницы
и так далее.По-моему хуже трудно придумать?
За mmkv спасибо, не знал.Иногда в срачах таки можно почерпнуть что-то полезное.
Я не понял, это bdb1 не рассыпался? Еще как сыпался с cyrus у нас. Так, что только удаляешь и пересоздаешь заново.
> Для андроида есть https://github.com/nhachicha/SnappyDBНо если вдруг оказывается, что мобильных ОСей более одной и нужно чтоб и под андройд и под яблоко норм и стабильно работало, да не нарушало каких-то огороженный требований..
> Для андроида есть https://github.com/nhachicha/SnappyDBSharedPreferences уже не в моде?
> На порядок быстрее и сериализация из коробки
Только вот обычно она применяется не для хранения ключа и значения...
+ миллионы мух которые садятся на скуль не могут ошибаться.
Этот тот редкий случай, когда миллионы мух случайно не ошиблись.
Они и не садяться. Пользователи то на самом деле даже не знают что они пользователи скулита.
Нуну, а потом приходится СоСи внедрять, чтобы мух, хранящих картиники в base64 стрингах в бд резинкой от трусов не били🙄
А ты не храни в base64, ты храни как BLOBы.
> А ты не храни в base64, ты храни как BLOBы.Да я ж не 🪰, мне и файлики норм.
> + миллионы мух которые садятся на скуль не могут ошибаться.Мухи садятся на информацию ?
Тот самый, из Audacity :)
За прошедшие годы в SQLite притащили кучу ненужного говна, а встроенной поддержки сравнения без учета регистра как не было, так и нет.
Притащили меганужные вещи, такие как UPDATE FROM (еще летом), и вот сейчас RETURNING.
Я уже бегу свои либы апдейтить и сам скулайт пересобирать (в дистрах он старый престарый, везде с собой приходится бинари таскать).
Используйте их amalgamated вариант – весь sqlite одним си файлом, результат обработки препроцессором. Удобно и портабельно, не надо никаких бинарей
Хотя, вы, наверное говорили о бинариках CLI-утилиты
Про сошечки и дллки. Не люблю статику, понимаете ли.
А кстати, как эту амальгату порезать ? Мне бы только crud оставить, не хочу десять мегабайт сорца таскать за собой.
На хомяке в разделе downloads есть "Snapshot of the complete (raw) source tree for SQLite version 3.35.2. See How To Compile SQLite for usage details."
И что ? вместо 10мб будет 5 файлов по 2Mb, это мягко говоря не то что мне надо.
Ну тогда придется не полениться и все сделать своими собственными ручками.
Спасибо, я в курсе.
COLLATE NOCASE ? Ну нет, так нет.
Куда печальнее когда нужно влинковать всякое ICU для нормального поиска с UTF-8, особенно под оффтопик... вот там немножко боль
Переходите на фряху, там влинковывание заключается в том, чтобы запустить make config и поставить галочку в нужном месте, а потом просто пересобрать.
Оффтопик это вообще боль, не только в SQLite.
> Ну нет, так нет.Берегитесь запятовой чумы!
UPSERT и RETURNING огонь. А это часть какого-то стандарта SQL и ещё какими-то стильными, модными, молодёжными СУБД применяется или специфично для SQLite?
Два миллиона лет уже постргресе. Значит и этой недобазе надо скопировать, чтобы быть «крутой». А раз модно всякие клоуны разработчики вместо ини файлов начинают настройки в скуль складывать потому что они тоже крутые))))
Да уж лучше в скуль, чем в json.
Ну все тогда будем накручивать функционал скуля пока он не будет жрать ресурсов как целая ОС.
Истины ради скулайт разрастается существенно медленнее чем мощность процессоров и среднее количество установленной оперативной памяти.
То что он разрастается уже жирный минус
То ли дело hello world - не способен расти в принципе, как и ваш интеллект
Вообще-то, в GNU hello можно ещё много чего напихать, почему это он не способен расти?
Нет. В нем не было достаточно очень нужных вещей.Например, всегда нехватало вышеупомянутого RETURNING, все время приходилось кроме самого запроса еще и нейтивную функцию sqlite3_last_insert_rowid вызывать. Мало того, приходилось для единообразной работы еще и сверять начало запроса - если это INSERT, то юзать sqlite3_last_insert_rowid, а если UPDATE или DELETE, то sqlite3_changes.
Еще сильно не хватало UPDATE FROM, где можно было апдейтить поля одной таблицы выборкой из других таблиц. Это, к счастью, прошлым летом добавили (хотя дистры не торопятся апдейтить sqlite, и он у всех годовой(!) давности).
Так что это жирный плюс.
Поддержу. За RETURNING это прям респект.
> Да уж лучше в скуль, чем в jsonнафиг это, только INI, только KISS
INI - одноуровневый отстой.
Если вы делаете многоуровневые настройки, значит чтото вы делаете не так.
Ну и как вы в одноуровневом INI сохраните такие настройки:
"button1": {
background: {
color: [12, 22, 33],
image: none,
},
foreground: {
color: [12, 22, 33],
image: none,
text-align: left
}
}вот так ?
[button1]
background.color=12,22,33
background.image=none
foreground.color=11,22,33
foreground.image=none
foreground.text-align=left
и будете копипастить десериализатор для всех .color и .image полей?
А ещё иногда бывают нужны несколько уровней вложенности. Допустим, я тут обломился, когда хотел сделать разные варианты упаковки в контекстном меню. Видимо, именно из-за формата. В итоге, только такой вот список (и даже в таком виде слишком много, пришлось убрать xz и zstd!=3), о выборе различных параметров и фильтров нечего и думать:
Как бы вам сказать? Конфигурация пишется и читается существенно чаще, чем код который её парсит и в норме всем должно быть пофиг на страдашки программиста, у которого "лапки" и лень копипастить... Особенно, если оный программист не в курсе того, что ini как формат поддерживает section nesting, хоть это и изрядно плохая идея.
Ну то есть копипастить, кто бы сомневался."Я угадаю говнокодера по первым шести словам комментария, а я по первым пяти".
Зачем угадывать, когда можно в зеркало посмотреть? А я, если что - вообще не кодер, а лицо эту ко-ко-ко-нфигуратиониззекод! Читающее и пишущее. И таки да, если прогнать её через притти-принтер, открыть в редакторе с подсветкой снитаксиса и прогнать линтером по завершению редактирования то блевать (почти) не хочется... Зато у индус-триального погроммизда лапки не болят и можна такой хоба! eval или там жысон.лоад и дальше тварить...
Так же как и в properties-файлах или в .reg файлах:button1.background.color=12,22,33
button1.background.image=none
....или вот
button1.background.color=12,22,33
*.*.image=noneкруто
Рокстар не согласился и проиграл
>This means that if a statement has a RETURNING clause that generates a large amount of output, either many rows or large string or BLOB values, then the statement might use a lot of temporary memory to hold those values while it is running.Бесполезно.
Бесполезно запихивать в RETURNING всякий хлам. Для этого SELECT.
А почему в сабже динамическая типизация? Разве это нормально?
Т.е. название SQLite тебе ни о чем не говорит. В приличном обществе это ругательство.
Это просто чудесно! А еще все хранится как текст. Если тип указана NUMERIC и в него положили Null 564 или строку - всё равно запишется.
Уже лет 5 как нет.
С версией 2-х годичной давности это работает: https://habr.com/ru/post/547448/#comment_22817694
Все не хранится как текст, числа хранятся как числа, блобы как бинарные данные, а текст как текст.
То, что вы можете положить в объявленное числом поле текст, никак на способ хранения данных не влияет.Детали тут: https://sqlite.org/fileformat.html, раздел 2.1. Record Format.
Это не отменяет того, что формат абсолютно дебильный. Зачем для каждого поля в каждой строке хранить тип, если можно его гвоздями прибить к типу в DDL и не хранить? Оверхед же меньше будет, флеха вообще спасибо скажет.
Формат не лучше и не хуже других. А именно такой по чисто историческим причинам.Флехе же на него фиолетово, оверхед можно не учитывать - основная нагрузка идет на чтение и обработку индексов. Зато так БД более гибкая и дружественная к юзеру (и позволяет прощать очень многие ошибки, а это именно то, что надо среднестатистическому программеру). И именно из-за этой простоты и дружественности конкурентов у sqlite (к сожалению) нет.
Не нравится? Идите к mysql, там гвоздями прибито, можно масштабировать и делать еще огромную кучу прекрасных и мощных вещей.
> Реализована поддержка выражения "ALTER TABLE DROP COLUMN" для удаления столбцов из таблицы и очистки ранее хранившихся в данном столбце данных.Уху!!! И ста лет не прошло !
Использовал в проекте. Редкостное олдскульное гавнище с кучей никогданенужного.
давай ссылку на проект, трепло
Проект в приват репе на гитхабе. Я-то использовал это дерьмо а ты? Любой движок бд, который умеет sql, лучше этого старперского кривого изделия. Ответь как там настройка нечувствительности к регистру работает)
В SQL регистрозависимое сравнение, вам в ANSI жалобу подавать надо ну или в ISO.
Кто-нибудь постарше 23 лет и с реальным опытом, подскажите уважаемые. Есть ли альтернативы? Нечто даже на расте помниться пилили недавно.
Просто из интереса.
Быстрее и надежнее нет ничего. За 8 лет (парк 250 АРМ) - базы крашились лишь пару раз , и то вместе с SSD/HDD.Просто почитать: https://habr.com/ru/post/547448/
На жабе апачевские дебри очень неплохи, а так чтоб скуль - без альтернатив (в том плане что не возьме оно так или иначе хуже склита).
>>>дебри очень неплохии очень неторопливы.
если только со времен ibm что-то существенно изменилось.
И если они не сделают удобный вариант для обрезания сорцов с нинужным функционалом то со следующими +10Мб - все что угодно будет лучше скулита.
Исходя из каких задач, какое окружение?
Честно говоря просто из интереса, но всё чаще это мобильные и пк игрушки. Ничего сверхсерьёзного.
Зачем SQL БД игрушкам?
Честное слово не задавался таким ворпосом - но если нырнуть в более менее сложные проекты, оказывается текстовика невообразимо мало.
FirebirdSQL, например.
Использовал его со времён InterBase, тогда ещё от Borland.
Написан на C++, может быть embedded.
Возможностей гораздо больше, чем у SQLite, поэтому и тяжелее.
А непопулярен он, возможно, из-за русских фамилий основных разработчиков.
А можно ссылку или проще даже тезисно в каких моментах тяжелее: ram, скорость записи/чтения или суммарно?
Так-то возможностей скулайта за глаза. Но предложение тут может породить спрос )
API у него зело сложный. Сразу видно, что разработчики не искали легких путей.В сравнении с ним скулайл как руби в сравнении с плюсами. Пока те плюсы выучишь, пока разберешься... А тут открыл бд, выполнил запрос, получил результат, закрыл бд.
API сложнее, используются многие сторонние библиотеки (re2 от Google, libtommath, libtomcrypt, ICU, ...).
SQLite тем и прекрасен (в том числе), что нужно всего два файла.
А в случае с Python (18% бекэнда на нем) - требуется 0 файлов, всё уже есть в "батарейках".
Русских фамилий? Еще один ударенный мифической русофобией на форуме?Громоздкий он, сложный, собирать и подключать тяжело. А скулайт взял и опа, все готово.
русские фамилии у разрабов говорят о качестве софта то же, что китайские или индийские
Нет.
Ну я понимаю, за державу обидно, но индийские - это ZoL posix layer, gluster (и, кажется, изрядная часть уже и ceph), а эти русские что сделали для хипхопа? Один nginx. (Ну и уже всеми забытый ank@ )
strace, например.
sphinxsearch (и его форк manticore).
7zip, который породил xz.
vitastor, пока в зачаточном состоянии, но вполне может вылиться во что-то серьёзное.Это то, что пришло в голову буквально за минуту, список, разумеется, куда больше.
Плюс в любом крупном opensource проекте найдутся русские коммитеры.
фар, винрар, дабл командир
вообще да, русские фамилии сегодня уже настораживают. Иногда приходится избегать, сам понимаешь, инфильтрация ФСБ в российское ИТ зашкаливает все мыслимые и немыслимые пределы.Но не думаю, что Firebird плох, скорее он хорош. Просто не совсем понятна ниша: для легковесного есть SQLite (еще один был, такой ще как он, запамятовал). А для большего - есть Postgres, MySQL... Firebird нечто среднее, его тяжело пропихнуть в проект именно поэтому. Как ты объяснишь менеджеру, почему он, а не PG, например? Или он, а не Sqlite ;?
Я все же не понимаю. Огромное количество русских фамилий свалило в кремниевую долину. Огромное количество русских фамилий аутсорсят на английские. Это все прекрасные профессионалы, пишущие отличный софт.При чем тут фсб? Это же не блобы, куда переименованные кгб будут засовывать все мыслимые и немыслимые бекдоры. Это опенсорс, который читают все, кому не лень.
Ну вава у человека в голове -- навязанная синтетическая реальность, в которой он "Всё Понимает" (tm)... а храбрости глаза разинуть и сверить с наблюдаемым -- нетути.PS: надо же, фраза в руку:
---
Но подлинная причина глубже; извращения как таковые носят, скорее, инструментальную роль. Тоталитарные идеологии могут сильно отличаться по риторике – они могут говорить про «высшую расу», или «передовой класс», или «угнетенные меньшинства», они могут воспевать солдатские портянки или, наоборот, розовые стринги – цель остается неизменной. Подчинение людей своей власти, принуждение их думать, верить, принимать решения так, как предписывает идеология. Власть является целью сама по себе. Важно даже не то, во что именно вас заставляют верить – в превосходство нордической расы, победу коммунизма во всемирном масштабе или возможность переделать женщину в мужчину (или наоборот) при помощи гормонов и операций. Важно, что содержание вашей головы – а значит, и ваши поступки – определяете не вы.
--- http://vz.ru/opinions/2021/3/16/1089501.html(причём Худиев там и Айка упоминает как одну из жертв такого тоталитаризма)
Загуглил за тебя, братишhttps://objectbox.io/sqlite-alternatives/
https://sourceforge.net/software/product/SQLite/alternatives
Ты это сейчас серьезно ? Больше так не делай братиш.
зашел по ссылке>>>SolarWinds Database Performance Analyzer
>>>MariaDB
>>>SQL Admin Toolset
>>>SAP HANAотличные альтернативы
тут за некоторых анонимов gpt-3 пишет, чтоль?
lmdb и metakit4. Только это не совсем альтернативы, всё очень зависит от задач.
> lmdb
> The entire database is exposed in a memory map, and all data fetches return data directly from the mapped memory, so no malloc's or memcpy's occur during data fetches.Ну это однозначно сильно специфичная штуковина. А второе это что такое ?
Встраиваемая документо-ориентированная база со схемой, заносимой в заголовок. Никакого жсона, плоские структуры, как если бы сырые си-структуры, только динамически. Очень старая вещь родом из 90х. Рабочих биндингов к python 3 нет. Есть кое-как портанутые к python 3 из python 2, но не очень хорошо работают. По-хорошему их нужно вообще переписать на `ctypes`, ибо cextы уже достали в край, ибо их при каждом обновлении пистона перекомпилять надо.
В общем, как принято на реддите, огромное спасибо всем отписавшимся! )
Понятно стало вдруг, что как сидели на скулайте, так и не стоит рыпаться. Как отписал первый человек - вот оно есть и пока не придумали лучше.
Т.к. лучше - это долгие годы пилинга и багов скулайта, дабы придти к тому же по сути.
Самая передовая база данных, насколько я понимаю, это https://github.com/gluesql/gluesql на движке https://github.com/spacejam/sled.
Но она только разрабатывается, в зачаточном состоянии.Если не загнётся, то в лучшем случае 3-5 лет ей нужно, чтобы настояться.
Есть ещё крайне перспективная (по рекламным заявлениям) это objectbox - https://docs.objectbox.io.Она может и сейчас подойти.
Но вот прям production-ready, с гарантией масштабирования по функционалу - только SQLite.
>разрешён выбор режимов "MATERIALIZED" и "NOT MATERIALIZED".Из нормального декларативного языка сделали императивную чепухню.
Вышла новая версия легковесного блоатваря. Ура, ура.
Неужели такое бывает ? И на какой строчке начинается блоатварь ?
Обеспечено преобразование "x IS NULL" и "x IS NOT NULL" в FALSE или TRUE для столбцов, имеющих признак "NOT NULL".
Это ктож так говнокодит
> Это ктож так говнокодитСоздатели скуля, утяжеляют код лишними ненужными фичами.
а что не так?
NULL - особая (причем, зачастую, разная) сущность в SQL, о чем в доке сикулайта есть даже отдельная страница https://sqlite.org/nulls.html - зайдите гляньте, там расписано что не так.
А IS и IS NOT разве вообще должны возвращать что-то отличное от boolean'а?
> Изначально в SQLite по умолчанию использовался режим "NOT MATERIALIZED", но теперь для CTE, используемых более одного раза, изменён на "MATERIALIZED".Лошары не умеют в оптимизацию запросов?
Контролирование материализации это и есть один из вариантов оптимизации запросов.
Как не зайду, так уже начирикано коментов, не успеваешь просто, работать еще же приходится...Хотел сказать, что Рич - гений. А еще он любит C и Tcl/Tk - хороший вкус. Еще Fossil - всяко лучше Гита
> не успеваешь просто, работать еще же приходитсяТут 90% - школьники, и каждый уже написал 2 Оракла, имеет персональную яхту и Била Гейса водителем.
> реализована поддержка выражения RETURNINGЯ джва года ждал!
> RETURNINGгосподи... это же чуть ли не с прошлого века в нормальных базах было.
И они все совсем не lite.
> не liteНу да, у них нет в названии "lite". А ты думал, если назвать "lite", то БД сразу станет lite?
Нет, а что?
Тот случай, когда можно процитировать классика: =избы мне по нраву!=
