Опубликован релиз SQLite 3.51, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64186
Хорошая вещь, кормит. Жаль только нет альтер тэйбл для существующей таблицы с позможностью вставить новую колонки между существующими, а только в самый конец
А оно таки надо? Нет, реально, учитывая, что порядок колонок в таблице вещь условная и может быть переопределен уже на клиенте (для гуя) или вообще не имеет значения (для ipc)
Оно начинает быть надо у горе программиста уже пятидесятый столбец и он продолжает использовать sqlite. Хотя ему ненужен ни sqlite ни такая большая таблица.
> только в самый конецу оракла также.
А вот и нет, я нашёл способ.Короче, делаешь всем полям кроме первого:
alter table TT modify Column_B invisible;
alter table TT modify Column_C invisible;
alter table TT modify Column_D invisible;А потом
alter table TT modify Column_C invisible;
alter table TT modify Column_D invisible;
alter table TT modify Column_B invisible;
И они уже в новом порядке
Сорян, во второй части уже "visible"
по крайней мере у старенького 11.2 - давообще конечно не нужно завязываться на select *
Где можно почитать рекомендации по индексам для sqlite?
А что не так с индексами?
Ну, если у приложения их нет. На что смотреть? Я вот взял и сделал в sqlitebrowser, время хорошее у чтения, но будто неэффективно теперь? И размер в 2 раза больше.
А как надо, в два раза меньше? Так не бывает. Индекс практически тоже таблица, только отсортированная и условно с двумя колонками, в одно ключ, в другой номер записи.
> А как надо, в два раза меньше? Так не бывает. Индекс практически
> тоже таблица, только отсортированная и условно с двумя колонками, в одно
> ключ, в другой номер записи.Файл сжимается в 10 раз и будто бы можно поэффективней? Операции с диском не бесплатные. Конечно хотелось бы оптимизировать записи, их и так под терабайт в день и это практически без нагрузки.
Учи структуры данных и реализуй самый лучшей для твоей задачи способ. Sqlite тебе вот ваще не нужен если проблемы о которых ты говоришь реальны.
> Учи структуры данных и реализуй самый лучшей для твоей задачи способ.
> Sqlite тебе вот ваще не нужен если проблемы о которых ты
> говоришь реальны.Тут проблема, что для sqlite нет sqlite_top -- пойди угадай, что оптимизировать.
Если базу можно сжать в 10 раз, то либо неэффективная структура таблиц (много пустого места, либо много одинаковых данных), либо используется ФС с неподходящими настройками (размер сектора) и т.д. Т.е. индексы на это вряд-ли влияют, это следствие, а не причина.
Как написали выше, разбирайся со структурами данных. Ну или нужна более подходящая для твоей задачи БД, может даже NoSQL.
Там время в таблицах. Т.е. тупо текст миллионы раз повторяющийся.
Ради хранения времени заводить целую базу, да еще с индексами? Либо не оптимальная структура, либо не только время хранится, а что-то еще.
Нет, там время у каждой записи с данными: created_at/updated_at/last_sync/remote_date. Все поля нужны для статистики и выборки, это минимум, к которому получилось придти (по хорошему ещё несколько полей со временем нужно добавить, но эти данные отправились в блоб с жсоном, над ними активных операций нет).
Т.е. есть повторяющиеся (в 10-кратном размере) данные времени? Тогда нужно использовать NoSQL базы, есть среди них т.н. "колоночные" базы, Clickhouse, например. Есть еще базы временных рядов - TSDB, например InfluxDB. Но по последней боюсь сейчас меня здесь "закидают помидорами". Тут недавно в новостях пробегала какая-то колоночная база, название не помню.
Ну в принципе норма, в sqlite время хранится в виде текста. В posgres с этим немного лучше, но бинарный формат сжимается хуже, так что выигрыша тут никак не получить. Так хоть бэкапы хорошо сжимаются.
Вроде как sqlite не для больших бд со сложными поисками по индексам?Если о таком задумываешься - наверное надо смотреть в сторону postgres или mssql
> Вроде как sqlite не для больших бд со сложными поисками по индексам?Я в одной "конторке" видел 16Тб базу он скулайте с довольно таки грамотной кучей связанных таблиц и народ очень даже доволен
16Тб? А с резервными копиями они там не мучаются?
rsync ?
> 16Тб? А с резервными копиями они там не мучаются?Мало того что не мучаются (благо только в одном брэнче два НАСа по 512 Тб) так они еще базу и редистрибьютают с rqlite
Вот кстати отличный пример никчемности sqlite как базы данных и тех кто её использует. С одной стороны запросы без индекса медленные с другой с индексами база пухнет. И ведь мега умы ведь додумались бы и оставить медленные запросы и так и пользвать в приложении. И ведь у этого юзера ведь так уже где то есть в проде.
> запросы без индекса медленные с другой с индексами база пухнетТы точно понимаешь как работают реляционные базы данных и индексирование?
Что ты, чёрт возьми, такое несёшь? (с)
У склайта проблема только одна - невозможность писать в несколько потоков (если я не отстал от жизни). Остальное Ваши фантазии.
Электрон среди баз данных.
Электрон заменяется на nwjs, а сабж на что?
Firebird
FoxPro
А чё сразу не postgres? Между прочим, sqlite встраиваемая.
Firebird, между прочим, тоже.
всем хватит и hashmap
csv таблички им хватит.
csv таблички тоже можно юзать из sqlite :)
Proton.
Чушь порешь. Электрон - это маразматическая идея на нормальном десктопе залезть внутрь браузера и пытаться делать ровно такие же десктоп приложения. Только на хтмл.
Ссыкулит - реально полезная вещь, используется тысячами программ и заменяет "монстро-СУБД".