Опубликован релиз SQLite 3.31.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg...Подробнее: https://www.opennet.me/opennews/art.shtml?num=52238
> Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы создать столбец, значение которого автоматически вычисляется на основе содержимого другого столбца.Знатоки, объясните: чем представления (view) хуже? Или я не понял и это вообще про другое?
Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя. Ну ещё все данные и их производные в одной таблице, не нужно писать в одну и читать из другой как это будет с view.
Спасибо, теперь стало более понятно.
>эту штуку можно не вычислять каждый раз, записав её на дискА от VIRTUAL тогда чем?
Тем, что не надо каждый раз выражение писать в select. Или делать отдельный view.
главное чтобы по нему можно было индекс строить
> Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя.В "больших" СУБД есть materialized view, тоже можно не вычислять каждый раз. Надеюсь, сабжевая фича является частью плана по их включению в SQLite.
Таким темпами он станет SQHeavy
Black Progressive Industrial Heavy SQL.
То, что надо!
VIEW, например, в постгресе - кошмарная и вредная конструкция, не дающая менять схему нижележащих таблиц, а для MATERIALIZED либо требующая блокировки, либо создающая кучу других проблем (в случае REFRESH CONCURRENTLY). Всё что угодно лучше этой гадости - функции, триггеры, обычные таблицы обновляемые запросом, CTE, в зависимости от того что применимо. Почему бы также и не вычисляемые столбцы, хотя по мне так их сфера применения тоже очень сильно ограничена (в основном обратной совместимостью).
С MV и в оракле тяжко, если много данных и обновление таблиц частое.
Чаще всего виртуальные столбцы используются для того, чтобы построить индекс по выражению.
В постгресе это можно делать и напрямую
Наверное прикольно. Но когда включат поддержку icu? что бы запрос Select "Ы" like "ы" выдавал 1?
известный баг\фича))
Раз не включают по умолчанию значит это никому не нужно. А полтора землекопа могут и сами себе с ICU собрать.
Если он начнет такое выдавать - да, это будет именно баг, поэтому ответ - никогда.А поддержка upper/lower - существует, но, поскольку это embedded db, collate function ты ей должен предоставить сам - https://sqlite.org/c3ref/create_collation.html - можешь себе "включить поддержку icu", если умеешь.
Для "неумеющих кодить" существует postgres.
> Для "неумеющих кодить" существует postgres.Домино — это вам не шахматы, тут думать надо.
Поддержка включена если собрать правильно
это не та поддержка, которую хочет аноним (если мы правильно понимаем его пример - он, вероятно, хотел все же не безусловно и во всех случаях чтобы Ы было like ы, а работающий collation ?)Это поддержка в cli, без которой предложенную им строку вообще набрать, скорее всего, не получится.
Никогда, в SQL like --- _регистрозависимый_.Для поиска независимо от регистра используют UPPER/LOWER или бывает делают ilike, но ilike нет в стандарте SQL, это расширение на усмотрение авторов СУБД.
Просто удобство. Не всегда хочется создавать отдельную сущность в виде view. В принципе можно и запросом разрулить.
Имхо творят сущностный для видимости деятельности. Ничем хорошим это обычно не заканчивается.
Полагаю, в этом случае закончится поддержкой materialized views, что неплохо.
SQLite - хороший, годный продукт. Но кажется легковесность потихоньку улетучивается.
embedded db не обязана быть "легковесной", ей надо быть - embeddable.А дальше, в случае sqlite все зависит от тебя - часть фич включается только по запросу, часть можно отключить. Но для этого его надо пересобирать, причем в некоторых случаях - из исходников.
Нет, sqlite-autoconf-3310000.tar.gz - это не исходник, и конфигурируется там не всё.
lite тоже не значит легковесный?
lite тоже не значит легковесный?
По объему он все еще очень легкий
бизнес-логика встраиваемая прямо в таблицы... каша будет...
Устраивать или нет кашу — выбор разработчика.
Да, есть такие любители - выдать толпе мыло, веревку и посмотреть что получится в итоге...
а получится как в расте (недавно), получится как в вордпрессе (перманентно)
В расте получился способ ускорить работу, отключая всякие проверки. В результате можно догнать по производительности такие языки, как C и C++.> получится как в вордпрессе (перманентно)
Если вас беспокоит безопасность — не пользуйтесь вордпрессом.
У вас на все есть ответ :)а как потом выгружить такие столбцы для переноса в другую базу? mysql например?
Также как из MySQL выгружать в PostgreSQL, а из оного - в Oracle, а оттуда в Redis. т.е. со всей логикой ровно никак - это разные базы с разными фичами, не прозрачно взаимозаменяемы и не должны такими быть. А если только данные, то брать и выгружать, и вычисляемые столбцы в этом только помогают, потому что помогают обеспечить совместимость и прозрачную конвертацию схемы. Собственно, никакую другую сложную бизнес логику в них и не запихнуть.
> У вас на все есть ответ :)Нас, анонимов, много. Хоть кто-нибудь, да ответит.
> а как потом выгружить такие столбцы для переноса в другую базу? mysql например?
Почему бы вам не спросить, как переносить из MySQL в SQLite пользователей и их права доступа, например?
Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.Не понял, что с UUID можно ли делать PK поле с UUID? Можно ли его генрить автоматический и получать на INSERT?
Будет ли когда нибудь обратный индекс для текста?
А чем integer не устраивает в плане индексирования?
Тем, что нужно делать [mYear, mMonth, mDay, mHour, mMinute, mSecond] по шесть полей на одну дату (и то если повезло и они в UTC), а если дат несколько, то это просто какой-то кошмар их создавать.В целом конечно можно и с UnixTime немного погеммороиться, но было б удобнее.
С unixtime, имхо, будет достаточно удобно, если для преобразования даты/времени в unixtime и обратно юзать какую-нибудь либу.В остальном - это же sqLITE. Преимущество должно быть в т.ч. в простоте.
Зачем? Еесть нативная поддержка, зачем юзать какую-то либу? Только чтобы не читать документацию?:)
Нет нативной поддержки, об том и тред.
Понял, «чукча не читатель, чукча писатель», в документацию религия не позволяет. Итак, смотрим https://www.sqlite.org/lang_datefunc.htmlCompute the date and time given a unix timestamp 1092941466.
SELECT datetime(1092941466, 'unixepoch');
Compute the date and time given a unix timestamp 1092941466, and compensate for your local timezone.
SELECT datetime(1092941466, 'unixepoch', 'localtime');
Compute the current unix timestamp.
SELECT strftime('%s','now');
the date and time given a unix timestamp 1092941466.
SELECT datetime(1092941466, 'unixepoch');
Compute the date and time given a unix timestamp 1092941466, and compensate for your local timezone.
SELECT datetime(1092941466, 'unixepoch', 'localtime');
Compute the current unix timestamp.
SELECT strftime('%s','now');И так далее, еще много всего.
Сразу добавлю, что функции эти существуют давно и надо было только документацию открыть.
это все же не тип данных DATE или DATETIME, это преобразования (впрочем, теперь вот их можно сложить в генерируемый столбец, только непонятно, для чего)Но, учитывая, что внутри самой sqlite существуют на самом деле только два типа данных - integer и string ;-) - совершенно непонятно, зачем эта имитация анониму.
>Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.Не будет. Есть integer. Если нужно искать только по времени, и времена уникальны, то кодируешь в число и засовываешь в integer primary key, будет сверхбыстрый поиск, ибо integer primary key идёт в rowid.
Если нужно искать по нескольким primary, то прикидываешь сколько бит нужно на каждый primary нужно и кодируешь всё в один rowid с помощью битовых операций. Поиск будет нормальный, нужно просто правильно запрос синтезировать. Единственный недостаток - слишком много надо ручками делать. Давно бы запилил то что нужно, но там PR принципиально не принимают, а значит любой вклад в эту базу - это зря потраченный труд и время.
индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?Обязательно заниматься неведомой херней?
Правильно они такие PR не принимают - эта проблема в голове у оверинжинирнутого разработчика, а не в софте, который вполне последовательно реализует sql, а не костыли.
>индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?любые индексы будут медленнее rowida. Их ещё добавлять и удалять надо, ибо со включёнными индексам вставки будут очень медленные. rowid же используется самой базой и связан с низкоуровневым представлением на HDD, поэтому последовательный доступ и поиск при кодировании в rowid будет быстрым.
Если у вас база в ведроприложении на несколько мегабайт, то вам пофиг. Если у вас многогоговая база на жёстких дисках, то вам не пофиг, будут импортироваться в неё данные неделю или 2 недели и будет 1 запрос идти минуту или 20 минут.
если у вас "многогиговая база на жестких дисках" не может работать банально с индексами потому что "вставки очень медленные", и вы вынуждены заниматься наколеночной "оптимизацией" с ручным складыванием битиков - вы что-то уже понапроектировали явно не то. Может вам вообще не нужен был sql (вручную битики перекладывать - вообще не то, для чего его задумали)?Возможно, именно sqlite для этого применения не очень подходил, хотя видел я немногогиговые (5-8 это ведь немного?) базы аж с FTS и весьма интенсивным добавлением данных в realtime - и ничего, жили.
А в многогиговой базе на орацле у нас по 20 минут выполняется только всякая аналитика, где запрос на четыре экрана мелким шрифтиком - да и то если кэш не прогрет. И никто там вручную rowid не собирает по битикам, что странно. Ну, правда, стоило это довольно дорого.
Ну-ну, ври, да не завирайся (с) Если обосновать полезность и реализуемость фичи - сделают. Да, код напишут сами по лицензионным соображениям. В свое время я предложил добавить компрессию для расширения FTS - показал результаты тестов с компрессией и без, прислал свою реализацию для проверки. В итоге идею приняли и компрессию добавили. Так что если вы измеряете результат полезностью - все отлично, если же вам попиариться принятым в апстрим кодом - тогда вон в кде шлите, там имхо вообще все принимают (в качестве подтверждения можете нагуглить мою давнюю переписку с разработчиками akonadi).
у них mailing list без TLS. отказываюсь таким пользоваться.
Или крестик сними ими или трусы одень (с) нет проблем написать напрямую на почту DRH - не припомню случая, чтобы он мне не ответил. Ах да, попиариться не выйдет :)
Лучше бы сборочную систему поправили, а то даже pread() и прочие фишки детектить не умеет, зато код их юзать умеет, если ручками задать дефайны при сборке.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241385
Тоже думаю что def это не простые фаилы если вы сможете собрать именно с этими дефами https://github.com/Griggorii/wine_d3d_def_source ваин то вот и напишите мне на почту гмаил ком ник тот же.
Считаю что есть такие инструменты программирования которые ты считаешь мусором потому что просто не знаешь как применять.
> Лучше бы сборочную систему поправилиона ж целиком вторична и делается на от..сь.
Но если ты поправишь - полагаю, такой патч вполне примут. Только вот разбираться в том, что генерит эту сборочную систему - себе дороже, и гораздо проще не париться, задав дефайны - не так их и бесконечно много.
P.S. соберешься править - сделай еще параметры для WAL и синхронной записи при нем - а то и их приходится вручную определять. Причем bsdшный мэйкфайл такому тоже не обучен.
P.P.S. мне лень, у меня и так все работает, да.
А для meson как подпроект кто-то уже сделал версию для встраивания?
Этот релиз SQlite3-3.31.0 приводит к ошибке сегментации Thunderbird и Firefox - пришлось откатываться на предыдущую версию и восстанавливать профили пользователя.