Опубликован релиз SQLite 3.42, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.me/opennews/art.shtml?num=59157
Ну и где это любители хранить 10 своих ценных настроек приложения в sqlite? Чтобы их приложуха была ого как у больших. И тормозила как у больших.
Хотя бы не обнуляются по каждому чиху, как у веб-браузеров (привет хромому).
Если у тебя 10 настроек храни их в текстовом файле. И не надо выпендриваться. Никуда файл по чиху не денется.
Тебе наверно нравится, когда твои пользователи тебя проклинают? А, да, какие пользователи, никаких, конечно. А гугловцам вот нравится очевидно.
За то что ты сделал все нормально? Ты с головой поссорился? Даже если у тебя 100 настроек зачем тебе sqlite ты их каждую секунду опрашиваешь и делаешь сложные запросы с сортировками? Сделай просто нормальное приложение и всё.
Что нормального в том, что пользовательские данные регулярно обнулятся, а в каком месте, это как повезёт? Сложные запросы это про надёжное хранение стейта и операции над ним или что-нибудь подобное, но тут уже заметно что это мать его sqlite и не полноценная бд. А вот надёжное хранение конфигов самое то для sqlite, на большее она не годится.
Да что вы все такое делаете что у вас у всех данные в файлах обнуляются? Может дело не в надежности, а просто в неумении проектировать приложения?
> Да что вы все такое делаете что у вас у всех данные
> в файлах обнуляются? Может дело не в надежности, а просто в
> неумении проектировать приложения?Топ 3 ситуаций, приводящих к невосполнимым потерям и повреждению данных: потеря питания/паника, исчерпание места на диске, падение программы/сегфолт/экцепшен. Все эти потери происходят в результате отсутствия ACID и такие вопросы никак не решаются на практике, раскажи о проектировании кому-нибудь другому.
>> Да что вы все такое делаете что у вас у всех данные
>> в файлах обнуляются? Может дело не в надежности, а просто в
>> неумении проектировать приложения?
> Топ 3 ситуаций, приводящих к невосполнимым потерям и повреждению данных: потеря питания/паника,
> исчерпание места на диске, падение программы/сегфолт/экцепшен. Все эти потери происходятМожет стоит в journal_mode = WAL попробовать?
Или вы тут про текстовые файлы?
С текстовыми файлами надо в create-fsync-rename уметь, и ничего обнуляться не будет.
Около 100% софта на этом сыпется.
Запуск второй копии программы, которая изменит часть текстовых данных, а первая копия об этом не узнает примерно никогда
А кто мешает сделать так программу, чтобы нельзя было запускать вторую копию ?
И как локальная БД спасет от "потеря питания/паника, исчерпание места на диске, падение программы/сегфолт/экцепшен" ?!
Поинтересуйся на досуге, что такое ACID, и как оно работает.
Используют какие-нибудь замечательные варианты использования файловых систем, с отключенными барьерами или железом, которое в барьеры не умеет - а чо, прозиводиетльность жеж.
> Используют какие-нибудь замечательные варианты использования файловых систем, с отключенными
> барьерами или железом, которое в барьеры не умеет - а чо,
> прозиводиетльность жеж.Дело не в барьёрах, это вообще фс рассыпаться будет наверно. Например, data=writeback точно может прекрасно повредить и забить мусором любой открытый на запись файл (даже .bash_history рута целиком, открытый где-то фоном, у меня такое было 1 раз). Данные браузеров повреждаются практически всегда. И при простых падениях программ, та же leveldb улетает на раз.
> Дело не в барьёрах, это вообще фс рассыпаться будет наверно. Например, data=writebackWriteback - так себе затея для ценных данных вообще, минимум ordered, а без барьеров - вообще только data=journal, и то в самых тяжёлых случаях может не помочь.
В целом я как раз об этом - о безумных вариантах использования, где by design именно так и должно случаться :)
Sqlite на чтения отмасштабироваться может ровно настолько насколько есть памяти и процессора в пределах машины на которой работает, на запись да, есть решаемые ограничения обход которых вроде как в процессе.
Да, я уже привык к database is locked по поводу и без. Малейший свопинг не даёт ей работать несмотря на выставленные приоритеты и всё остальное -- нет записи, откат, данные копятся, память ещё уменьшается.Но, запросы тоже весьма не быстро отрабатывают, веб интерфейсу приходится ждать свежие данные каждый раз, в самой sqlite по понятным причинам не возможны нормальные кеширование и оптимизация запросов. Даже открываешь табличку на 100к записей и уже ждёшь секунду. Часто отрабатывает медленнее, чем хотелось бы, приходится прикручивать редис. Ограничения по типам полей, опять же.
Лучше, чем голые файлы, хуже, чем подходящая задаче бд. Даже для статики в бд, как я слышал, есть эффективные поделки от Sybase. Но sqlite хотя бы экономная. Не уверен насчёт процессора, но по стораджу вполне.
Для альтернативно одаренных документ написан https://www.sqlite.org/appfileformat.html зачем и почему стоит рассмотреть как хранилище состояния и настроек
алло, ты о чем вообще? вот эти сверху, иксперды опеннета, что минусуют и советуют настройки в файле хранить, сроду ничего не читали и не разрабатывали ни одного приложения
Ну все какой-то рекламный наброс всё выключаем голову и везде где не надо суем скуль. Потому что программы мы писать не умеем только копипастим из инета.
> Потому что программы мы писать не умеем только копипастим из инетахорошо, что признался
Хто мне блджад расскажед, зойчем хронимые пирацедуры в эмбедовом двиге, который априори обвязан логикой аппликухи? Маразм?
(это я про CG/SQL)
> Маразм?Facebook!
В жизни большинства так называемых профессиональных программистов наступает момент, когда они перестают себе доверять окончательно. Мир для них распадается на более хорошие технологии и менее хорошие. Более хорошие - там где он исторически делал меньше позорных ляпов. Одно дело хранимка на экран, и другое дело переусложненный код, который он привык писать обычно. Кажется безопаснее.
> В жизни большинства так называемых профессиональных программистов наступает момент, когда
> они перестают себе доверять окончательно.Именно в этот момент их надо метлой гнать из профессии.
надеюсь, с тобой поступили в соответствии с твоими же рекомендациями
Меня за щито? Я себе доверяю. Не полностью, но таки да.
> CG/SQL позволяет оформить хранимые процедуры на специальном диалекте T-SQL (Transact-SQL), допускающем вызов функций стандартной Си-библиотеки и обращение к данным в SQLite.Ну каг для чего? Неужели ты не хочешь на T-SQL написать вебсервер, который можно будет стартонуть специальным запросом? Подобалять в него потом коллбеков с бузинесс-логикой твоего приложения и сделать настолько дичайшую дичь, подпёртую базой, что все кто увидит код, будут убегать из конторы в жэстачайшэм афиге. Всякие тарантулы и нжинкс-юниты - просто курят в сторонке.
пох, перелогинься :)Вот что да, то да. Обязательно этим займусь, когда выйду на пенсию и окончательно впаду в дичайшее уныние по головному контуру :D
Я не пох и ничего не имею с ним общего.> когда выйду на пенсию и окончательно впаду в дичайшее уныние по головному контуру :D
Это уже не будет иметь особого смысла. Это надо делать сейчас, чтобы вырасти незаменимым специолиздом, которого все ценят и уважают. Но продвинуть такие решения можно только с чистого листа в гринфилд-проекте, ибо рынок уже давно перегрет массой решений разной степени вменяемости, быстродействия и применимости.
>> когда выйду на пенсию и окончательно впаду в дичайшее уныние по головному контуру :D
> Это уже не будет иметь особого смысла.Пайчему. Стану работающим пенсионером, устроюсь незаменимым специолиздом, буду пить смузи.
>Adobe, Oracle, Mozilla, Bentley и BloombergА Google где? Они во всю sqlite в своем ведроиде используют и даже копеечкой не поделились
MS с гуглом кмк просто попросили их не палить :D
Думаю CG/SQL тут не уместен, т.к. sqlite это удобная встраиваемая записная книжка. Функции это про реализацию логики на стороне БД, это хорошо на базе Postgres делать, где БД как сервер который отвечает на запросы от соединений. Там и тригеры уместны и другие плюшки. В эмбедед все это не нужно т.к. способна дообработать полученную выборку непосредственно в коде, и это тоже самое по затратам что в sql запросе передавать данные в функцию расширения. Как говорят тайцы сэйм сэй бат дифирент.
Перечитал. Они там компилятор хранимок сделали в код, для макак, которые с хранимок слезть не могут.
Представьте, что в каком-нибудь столбце у вас сложный хеш, который штатными средствами скулайт не вычислить. Писать через код приложения - это select, а по результатам update, а значит лишние действия. А если этот хеш написать хранимкой на C, то не надо select делать. Да мало ли еще применений? Кто-кто почту по триггеру отправляет из хранимок, кто-то в active directory ходит.
> А если этот хеш написать хранимкой на C, то не надо select делатьЧо. Данные магически из базы выберутся через атсpал?
> Кто-кто почту по триггеру отправляет из хранимок, кто-то в active directory ходит.
Кто-то трусы через голову надевает, но это не повод...
Или это было про постпроцессинг данных в одном запросе?
Ну разве что, потому что в нормальные курсоры оно не умеет :(
Плюсанул за пример с обсчётом внутри запроса, вполне валидно, да.
Другое таки дело, что я не вижу смысла считать сложный хеш внутри UPDATE, ну да ладно.
как DuckDB подружить с Delphi ?