SQLite 3.51

Многопользовательский режим планируется к внедрению?

https://github.com/tursodatabase/turso

А смысл? Пусть каждая система свою задачу хорошо выполняет.

У меня есть опыт разработки программ, работающих по выбору либо в локальном (SQLite) либо клиент-серверном (PostgreSQL) режимах, 80-90% запросов выглядят одинаково, там, где есть различия или нужна оптимизация, делаются разные ветки, но в целом проект сохраняет единую кодовую базу. Для унификации доступа со стороны клиента используется QtSql.

И такой подход мне нравится гораздо больше, чем навьючивание многопользовательских фишек на встраиваемую, вообще-то, СУБД.

Многия лета сабжу!

С какой радости? Это библиотека.

Многопользовательский режим планируется к внедрению?

Для этого можно использовать встраиваемый Firebird: https://firebirdsql.org/file/documentation/html/en/firebirddocs/qsg5/firebird-5-quickstartguide.html#qsg5-config-gsec-adduser

Firebird allows the creation of many different user accounts. Each of them can own databases and also have various types of access to databases and database objects it doesn’t own.

А посоветуйте пожалуйста хорошую с++ библиотеку для работы c sqlite (не qt, но примерно как в qt). Я искал, но то что нашёл показалось сильно сложным.

ща проще можн

локально duckdb - она по сути постгресс только колоночно и локально

либо ваще postgresql wasm - тады отличие локальной от серверной только если локальные запросы будут опираться на монопольность тады при запросе сервера будет криво

ваще апликуха не должна знать какая бд :)

А посоветуйте пожалуйста хорошую с++ библиотеку для работы c sqlite

https://github.com/SRombauts/SQLiteCpp

Смотря с какой целью. Многие фреймворки имеют биндинги в SQLite. Если хочется бекенд писать, то Drogon, например. Если нужен комбайн, то Poco. А так у него своё довольно простое API имеется. Дергай хоть из C, хоть из C++...

Попробуй sqlite

У https://github.com/rbock их несколько, под разные стандарты C++.
Если хочется ORM, то есть https://github.com/fnc12/sqlite_orm.

Попробуй sqlite

Он показался мне слишком сложным и далёким от c++. Я ищу что-то вроде qt-шного подхода.

Хороший, годный проект, когда для какой-то приблуды нужно что-то хранить, но поднимать сервер БД оверкилл, а возней с файлами (привет Столяров!) не хочется себе усложнять жизнь)

Как он может быть далёким от C++, если C это буквально подмножество C++?

Как он может быть далёким от C++, если C это буквально подмножество C++?

А Java - подмножество JavaScript!

Он не использует расширенные возможности с++, ограничиваясь только возможностями си.

Ну вообще, если тебе нужна ТОЛЬКО SQLite - разумно использовать её API. Прелесть Qt в том, что она даёт обёртку, абстрагированную от СУБД. Ну да, работать с char* в прикладном коде слегка уныловато. Но такого уровня обёртку можно и самому сделать.

Для унификации доступа со стороны клиента используется QtSql.

Ужасно конечно. Ради того, чтобы чуть поменять запрос между двумя СУБД тащить в проект конского слона под названием QT… который вообще задумывался как «окошечки» и таковым по сути и должен оставаться, не пытаясь быть швейцарским ножом.

Прелесть Qt в том, что она даёт обёртку, абстрагированную от СУБД.

Такую же прелесть бы дал собственноручно написанный класс на C++ длиной строчек в 100, который бы как-то решал ту же задачу без этого конизма.

SQLite в целом недолюбливаю за закрытость. Оно конечно теоретически всё такое опенсурсное, но там авторитаризм в разработке жесточайший. Чуть менее чем никакое нововведение в этом проекте со стороны человека, лично не бухавшего с автором, не будет принято в проект никогда. Проще в постгрес потратить 5 лет на срачь в мейллисте и впилить патч, чем в SQLite. Ну и в большинстве случаев это дикий оверкилл и пушка по воробьям. Для фиксации простейших изменений на диске, которые бы влезли в детский JSON на 4 килобайта, люди готовы посылать целые SQL запросы, вовлекая в задачу сложнейший движок. Йоба жесть треш содомия угар.

Рекомендация для всех, кто пытается в своём софте локально что-то похранить на диске: просто запишите это в файл через open() + write() + close() с чексуммами и будет офигенно. Чтобы записать надёжно, просто используйте идею «double buffer» - держите просто два файла - последняя версия и предыдущая, а новую всегда записывайте вместо предыдущей - если вы упадёте посередине, у вас всегда останется текущий, с которого вы поднимитесь. И не записывайте сразу в файл с финальным именем, а пишите в .tmp, закрывайте и потом атомарно rename. На старте просто всасывайте в память весь файл, при необходимости зафиксировать на диске - просто записывайте всю структуру данных обратно (через вышеописанную технологию). У вас там скорее всего нет 30 мегабайт сериализованных данных, да и те запишутся за 200 миллисекунд вместе с сериализацией (проверено). В этой истории даже простейший бинлог приделать несложно, если приспичит, реализуя его как добавление в конец файла бинлога страниц, наполненных новыми операциями с данными. Каждая страница должна содержать CRC и ссылку на предыдущую внутри, блохчейн в общем почти. Делается за два вечера элементарно. Не прочитался бинлог, побился блок в бинлоге - открыл следующий файл бинлога и продолжил в нём. Масса простейших способов сделать это надёжно. А про битые недозаписанные физические сектора пусть журнал EXT4 или XFS думает, зря он чтоли.

тащить в проект конского слона под названием QT

Действительно, зачем ты тащишь в проект QuickTime?

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

Ты пробовал? Можешь показать свой отклонённый патч?

Скулит

Рекомендация для всех, кто пытается в своём софте локально что-то похранить на диске

Добавлю совет свой софт писать на зиге, и файл открывать через mmap как арену — без парсинга структур.

а зачем вообще велосипедить

либо «import sqlite|duckdb» либо «„import fs“»

вот ваши вело-абзацы онеж для безОСных решений

в идеале это(хранимая часть памяти) должно подключатся к текущему состоянию «оперативной памяти» с полной прозначностью по ссылкам указателям взаимно с

вон для приплюснутых ранее упоминал https://www.codefarms.com/sdpbook

Serialization and Persistent Objects: Turning Data Structures into Efficient Databases

та ды можно и без «отдельного» файло/сукля сериализатора-хранатора

Ты пробовал? Можешь показать свой отклонённый патч?

Не всё в мире обязательно пробовать, чтобы знать что это плохо. Попадать под камаз, жрать кал и т.п. вовсе не обязательно делать лично!

а зачем вообще велосипедить

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

в идеале это(хранимая часть памяти) должно подключатся к текущему состоянию «оперативной памяти» с полной прозначностью по ссылкам указателям взаимно с

Не-не, такое никогда делать не надо, потому что это жесть как ненадёжно, непрозрачно. Сериализовать и записывать на диск всегда надо только явно через write. Можно читать пробовать через mmap конечно.

дядя(:()

речь не про тюнинг ака муравьиный алго из уже известного человечеству пространства решений с ея топологией и под конкретную задачу выбор оптимума

речь именно про твой велос на двух абзацах который актуальный при отсутсвии оси и лимитах на алго сложность реализации подсистемы «персистентности памяти» обусловленную например ограничениями по памяти(оперативе) и по памяти у кодемартышек

принцип инкапсуляции сложности в подсистем(у/ы) стандартная инженегрная фича - и ваще привнесённая сложность при тотальной интеграции подсистем в сверхбыстрый монолит обладает положительным roi только при мульти(тиражности/мультимультизапросахВпикоСекунду)

так что либо сервис штатный файловой системы ОСи достаточен либо какой (no)sql engine

ваше же дядя решение это колхоз 70 лет без урожая

ты книфку(<300 страниц) пролистай хотьбы а? - по сути там pickle для сипипи - со своими обручами и гамаками - по факту позволяет при надёжном диске иметь live-систему подобно классическим lisp smalltalk pharo и прочих ух-интерпретирующим системам

ваще Программист-Нафигатор Бахмана 1973 лекция тьюринга очень полезна для лучшей калистеники

https://en.wikipedia.org/wiki/Serialization

http://rkka21.ru/docs/turing-award/cb1973r.pdf

ваще sql декларативен( :) пролож прям) setl ваще так множеств язык

забавно как велосипедостроители не отдупляют в структуры (даже без хранения) данных и алго под них

ты книфку(<300 страниц) пролистай хотьбы а? - по сути там pickle для сипипи - со своими обручами и гамаками - по факту позволяет при надёжном диске иметь live-систему подобно классическим lisp smalltalk pharo и прочих ух-интерпретирующим системам

Серьёзное ненужно.

Улучшено сопротивление поломки файла

сопротивление чему? поломкЕ

CrX developers, developers корректорз, корректорз ))

Исправил, но вообще есть специальная тема: Ошибки и опечатки в новостях (4)

специальная тема

это сложно… запилите в «уведомить модераторов»! ))

запилите в «уведомить модераторов»!

Давно есть. В ОП новостей, статей и скриншотах есть особая форма уведомлений – «Проблема Опечатка или форматирование» с пользовательским комментарием.

ухтыблин, круто! ))

Хорошо. Можешь показать ЧЕЙ-НИБУДЬ патч в SQLite, отклонённый по причине «лично не бухал с автором» или что-то вроде того?

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

ЕМНИП, то в этом прикол с Public Domain. Логика в том, что SQLite как бы разрабатывается почти одним человеком, что снимает всякие конфликтные ситуации с правами на код. Если кратко: да, Public Domain, но автор Р. Хипп. Из этого следует тягомотина с патчами, которая превращается в историю, что как бы Р. Хипп пишет код, а вы его только консультируете, как реализовать ту или иную новую фичу. Поскольку от вас заимствуется ровно 0 бит кода, то и предъявить свои права вы не можете.

Рекомендация для всех, кто пытается в своём софте локально что-то похранить на диске: просто запишите это в файл через open() + write() + close() с чексуммами и будет офигенно.

Ровно до первого поиска/индекса.

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

Зачем опять что-то велосипедить и приделывать, если уже есть всё готовое и оттестированное со всевозможными интеграциями?

Зачем опять что-то велосипедить и приделывать, если уже есть всё готовое и оттестированное со всевозможными интеграциями

Про велосипеды фраза тупая, велосипеды постоянно совершенствуют и делают с нуля заново, когда хотят под себя. Затем, что космолёт не нужен, нужны две гайки из него. Зачем таскать с собой какой-то фактически проприетарный кусок неподдерживаемого тобой нечта, что когда развалится ты не сможешь быстро пофиксить…

Базового индекса в виде массива смещений в памяти с бинпоиском по нему хватит 99% тут собравшихся под их задачу. Бахните STL-контейнеров в памяти и всего делов, зачем вам серьёзные B+tree под жалкие 50000 записей.

проприетарный кусок неподдерживаемого тобой нечта

С таким же успехом, можно аналогичные предъявы кинуть C++ компилятору и его либам. С какой регулярностью участвуете в собраниях комитета ISO по вопросам развития новых стандартов C++?

развалится ты не сможешь быстро пофиксить

Если что-то и развалится, то вряд ли это будет сам SQLite.

С таким же успехом, можно аналогичные предъявы кинуть C++ компилятору и его либам. С какой регулярностью участвуете в собраниях комитета ISO по вопросам развития новых стандартов C++?

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

Если что-то и развалится, то вряд ли это будет сам SQLite.

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

ЕМНИП, то в этом прикол с Public Domain. Логика в том, что SQLite как бы разрабатывается почти одним человеком, что снимает всякие конфликтные ситуации с правами на код. Если кратко: да, Public Domain, но автор Р. Хипп. Из этого следует тягомотина с патчами, которая превращается в историю, что как бы Р. Хипп пишет код, а вы его только консультируете, как реализовать ту или иную новую фичу. Поскольку от вас заимствуется ровно 0 бит кода, то и предъявить свои права вы не можете.

А зачем это всё объяснять. Объяснять почему какашки воняют. Важно что они воняют и поэтому от них отказываются. Результат же важен, а не почему так сложилось. Да посрать почему, кому они уже интересны-то.

Основной мой поинт - заведи в памяти std::unordered_map и тебе точно хватит. Когда надо будет заперсистить на диск - сериализуешь как-нибудь да и всё. Если надо два индекса, ну значит у тебя будет два std::unordered_map

Опять-таки, есть примеры, когда Р. Хипп отказал кому-то без должных оснований?

Кстати, из официальной документации:

The fact that SQLite is embedded and serverless instead of being client/server is a feature, not a bug.

А почему Вы у меня спрашиваете? Это lesopilorama тут суету наводит.

Когда надо будет заперсистить на диск - сериализуешь как-нибудь да и всё. Если надо два индекса, ну значит у тебя будет два std::unordered_map

Мне, например, такое не подходит, у меня несколько миллионов записей, которые собираются днями. Если процесс по какой-то причине будет аварийно завершён, то все эти записи пропадут. То есть мне нужно периодически синхронизироваться с диском. Sqlite для этого отлично подходит - я просто дописываю новые данные в таблицу и даже если процесс будет аварийно завершён, то записи останутся.

Реализовать это надёжно вручную конечно можно, но это долго и чревато как раз потерей данных при ошибках.

Мне, например, такое не подходит, у меня несколько миллионов записей, которые собираются днями. Если процесс по какой-то причине будет аварийно завершён, то все эти записи пропадут.

Не пропадут. Ты же держишь их на диске. А все новые записи - в бинлоге. Пришла запись - записал в бинарном виде в конец файла «бинлог». Каждый час все данные из памяти и бинлога сериализуешь на диск в новый снепшот размером мегабайт в 30 - это займёт примерно 200 миллисекунд. Делается это всё за несколько вечеров на самом деле, зато ты точно видишь что там у тебя как лежит, что происходит и всё супер предсказуемо и в сравнении с огромным движком SQLite представляет собой простейшое контролируемое изделие.