Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз СУБД SQLite 3.31 с поддержкой генерируемых столбцов"	+/–
Сообщение от opennews (??), 23-Янв-20, 11:31
Опубликован релиз SQLite 3.31.0, легковесной СУБД, оформленной в виде подключаемой библиотеки. Код SQLite распространяется как общественное достояние (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в который входят такие компании, как Adobe, Oracle, Mozilla, Bentley и Bloomberg... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52238
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 23-Янв-20, 11:31	–1 +/–
> Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы создать столбец, значение которого автоматически вычисляется на основе содержимого другого столбца. Знатоки, объясните: чем представления (view) хуже? Или я не понял и это вообще про другое?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #22

2. Сообщение от Аноним (2), 23-Янв-20, 11:36	–3 +/–
Наверное прикольно. Но когда включат поддержку icu? что бы запрос Select "Ы" like "ы" выдавал 1? известный баг\фича))
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5, #7, #15, #36

3. Сообщение от PavloT (?), 23-Янв-20, 11:42	–1 +/–
Просто удобство. Не всегда хочется создавать отдельную сущность в виде view. В принципе можно и запросом разрулить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6

4. Сообщение от Аноним (4), 23-Янв-20, 11:42	+2 +/–
Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя. Ну ещё все данные и их производные в одной таблице, не нужно писать в одну и читать из другой как это будет с view.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #10, #12, #13

5. Сообщение от Аноним (5), 23-Янв-20, 12:04	+/–
Раз не включают по умолчанию значит это никому не нужно. А полтора землекопа могут и сами себе с ICU собрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

6. Сообщение от Аноним (5), 23-Янв-20, 12:05	–7 +/–
Имхо творят сущностный для видимости деятельности. Ничем хорошим это обычно не заканчивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #16

7. Сообщение от пох. (?), 23-Янв-20, 12:07	–1 +/–
Если он начнет такое выдавать - да, это будет именно баг, поэтому ответ - никогда. А поддержка upper/lower - существует, но, поскольку это embedded db, collate function ты ей должен предоставить сам - https://sqlite.org/c3ref/create_collation.html - можешь себе "включить поддержку icu", если умеешь. Для "неумеющих кодить" существует postgres.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #20

8. Сообщение от Аноним (8), 23-Янв-20, 12:14	+6 +/–
SQLite - хороший, годный продукт. Но кажется легковесность потихоньку улетучивается.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #9, #41, #44

9. Сообщение от пох. (?), 23-Янв-20, 12:27	+/–
embedded db не обязана быть "легковесной", ей надо быть - embeddable. А дальше, в случае sqlite все зависит от тебя - часть фич включается только по запросу, часть можно отключить. Но для этого его надо пересобирать, причем в некоторых случаях - из исходников. Нет, sqlite-autoconf-3310000.tar.gz - это не исходник, и конфигурируется там не всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #40

10. Сообщение от Аноним (1), 23-Янв-20, 12:32	+/–
Спасибо, теперь стало более понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

11. Сообщение от ыы (?), 23-Янв-20, 12:55	–1 +/–
бизнес-логика встраиваемая прямо в таблицы... каша будет...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #17

12. Сообщение от Аноним (12), 23-Янв-20, 12:56	–2 +/–
>эту штуку можно не вычислять каждый раз, записав её на диск А от VIRTUAL тогда чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #14

13. Сообщение от Аноним (14), 23-Янв-20, 12:59	+/–
> Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя. В "больших" СУБД есть materialized view, тоже можно не вычислять каждый раз. Надеюсь, сабжевая фича является частью плана по их включению в SQLite.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #27

14. Сообщение от Аноним (14), 23-Янв-20, 13:00	+3 +/–
Тем, что не надо каждый раз выражение писать в select. Или делать отдельный view.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #33

15. Сообщение от Аномномномнимус (?), 23-Янв-20, 13:00	+1 +/–
Поддержка включена если собрать правильно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #26

16. Сообщение от Аноним (14), 23-Янв-20, 13:01	+/–
Полагаю, в этом случае закончится поддержкой materialized views, что неплохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

17. Сообщение от Аноним (14), 23-Янв-20, 13:02	+1 +/–
Устраивать или нет кашу — выбор разработчика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #18

18. Сообщение от ыы (?), 23-Янв-20, 13:04	–1 +/–
Да, есть такие любители - выдать толпе мыло, веревку и посмотреть что получится в итоге... а получится как в расте (недавно), получится как в вордпрессе (перманентно)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19

19. Сообщение от Аноним (14), 23-Янв-20, 13:13	+/–
В расте получился способ ускорить работу, отключая всякие проверки. В результате можно догнать по производительности такие языки, как C и C++. > получится как в вордпрессе (перманентно) Если вас беспокоит безопасность — не пользуйтесь вордпрессом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #21

20. Сообщение от Аноним (14), 23-Янв-20, 13:15	+5 +/–
> Для "неумеющих кодить" существует postgres. Домино — это вам не шахматы, тут думать надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

21. Сообщение от ыы (?), 23-Янв-20, 13:16	–1 +/–
У вас на все есть ответ :) а как потом выгружить такие столбцы для переноса в другую базу? mysql например?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23, #25

22. Сообщение от Аноним (22), 23-Янв-20, 13:23	+5 +/–
VIEW, например, в постгресе - кошмарная и вредная конструкция, не дающая менять схему нижележащих таблиц, а для MATERIALIZED либо требующая блокировки, либо создающая кучу других проблем (в случае REFRESH CONCURRENTLY). Всё что угодно лучше этой гадости - функции, триггеры, обычные таблицы обновляемые запросом, CTE, в зависимости от того что применимо. Почему бы также и не вычисляемые столбцы, хотя по мне так их сфера применения тоже очень сильно ограничена (в основном обратной совместимостью).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #30, #50

23. Сообщение от Аноним (22), 23-Янв-20, 13:29	+4 +/–
Также как из MySQL выгружать в PostgreSQL, а из оного - в Oracle, а оттуда в Redis. т.е. со всей логикой ровно никак - это разные базы с разными фичами, не прозрачно взаимозаменяемы и не должны такими быть. А если только данные, то брать и выгружать, и вычисляемые столбцы в этом только помогают, потому что помогают обеспечить совместимость и прозрачную конвертацию схемы. Собственно, никакую другую сложную бизнес логику в них и не запихнуть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

24. Сообщение от Аноним (24), 23-Янв-20, 16:46	–1 +/–
Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям. Не понял, что с UUID можно ли делать PK поле с UUID? Можно ли его генрить автоматический и получать на INSERT? Будет ли когда нибудь обратный индекс для текста?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28, #31

25. Сообщение от Аноним (14), 23-Янв-20, 16:50	+1 +/–
> У вас на все есть ответ :) Нас, анонимов, много. Хоть кто-нибудь, да ответит. > а как потом выгружить такие столбцы для переноса в другую базу? mysql например? Почему бы вам не спросить, как переносить из MySQL в SQLite пользователей и их права доступа, например?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

26. Сообщение от Аноним (26), 23-Янв-20, 17:57	+/–
это не та поддержка, которую хочет аноним (если мы правильно понимаем его пример - он, вероятно, хотел все же не безусловно и во всех случаях чтобы Ы было like ы, а работающий collation ?) Это поддержка в cli, без которой предложенную им строку вообще набрать, скорее всего, не получится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

27. Сообщение от Q2W (?), 23-Янв-20, 18:01	–1 +/–
Таким темпами он станет SQHeavy
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #29

28. Сообщение от Q2W (?), 23-Янв-20, 18:06	+/–
А чем integer не устраивает в плане индексирования?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #42

29. Сообщение от Аноним (14), 23-Янв-20, 18:50	+6 +/–
Black Progressive Industrial Heavy SQL. То, что надо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

30. Сообщение от Аноним (30), 23-Янв-20, 21:01	+1 +/–
С MV и в оракле тяжко, если много данных и обновление таблиц частое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

31. Сообщение от Аноним (31), 23-Янв-20, 21:13	+/–
>Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям. Не будет. Есть integer. Если нужно искать только по времени, и времена уникальны, то кодируешь в число и засовываешь в integer primary key, будет сверхбыстрый поиск, ибо integer primary key идёт в rowid. Если нужно искать по нескольким primary, то прикидываешь сколько бит нужно на каждый primary нужно и кодируешь всё в один rowid с помощью битовых операций. Поиск будет нормальный, нужно просто правильно запрос синтезировать. Единственный недостаток - слишком много надо ручками делать. Давно бы запилил то что нужно, но там PR принципиально не принимают, а значит любой вклад в эту базу - это зря потраченный труд и время.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #32, #45

32. Сообщение от пох. (?), 23-Янв-20, 21:33	+/–
индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит? Обязательно заниматься неведомой херней? Правильно они такие PR не принимают - эта проблема в голове у оверинжинирнутого разработчика, а не в софте, который вполне последовательно реализует sql, а не костыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #35

33. Сообщение от ананим.orig (?), 23-Янв-20, 23:32	+/–
главное чтобы по нему можно было индекс строить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

34. Сообщение от Ivan_83 (ok), 23-Янв-20, 23:43	+/–
Лучше бы сборочную систему поправили, а то даже pread() и прочие фишки детектить не умеет, зато код их юзать умеет, если ручками задать дефайны при сборке. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241385
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #39

35. Сообщение от Аноним (31), 24-Янв-20, 01:31	+/–
>индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит? любые индексы будут медленнее rowida. Их ещё добавлять и удалять надо, ибо со включёнными индексам вставки будут очень медленные. rowid же используется самой базой и связан с низкоуровневым представлением на HDD, поэтому последовательный доступ и поиск при кодировании в rowid будет быстрым. Если у вас база в ведроприложении на несколько мегабайт, то вам пофиг. Если у вас многогоговая база на жёстких дисках, то вам не пофиг, будут импортироваться в неё данные неделю или 2 недели и будет 1 запрос идти минуту или 20 минут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #38

36. Сообщение от Аноним (36), 24-Янв-20, 02:08	+/–
Никогда, в SQL like --- _регистрозависимый_. Для поиска независимо от регистра используют UPPER/LOWER или бывает делают ilike, но ilike нет в стандарте SQL, это расширение на усмотрение авторов СУБД.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

37. Сообщение от Аноним (37), 24-Янв-20, 08:21	–2 +/–
Тоже думаю что def это не простые фаилы если вы сможете собрать именно с этими дефами https://github.com/Griggorii/wine_d3d_def_source ваин то вот и напишите мне на почту гмаил ком ник тот же. Считаю что есть такие инструменты программирования которые ты считаешь мусором потому что просто не знаешь как применять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

38. Сообщение от пох. (?), 24-Янв-20, 10:49	+1 +/–
если у вас "многогиговая база на жестких дисках" не может работать банально с индексами потому что "вставки очень медленные", и вы вынуждены заниматься наколеночной "оптимизацией" с ручным складыванием битиков - вы что-то уже понапроектировали явно не то. Может вам вообще не нужен был sql (вручную битики перекладывать - вообще не то, для чего его задумали)? Возможно, именно sqlite для этого применения не очень подходил, хотя видел я немногогиговые (5-8 это ведь немного?) базы аж с FTS и весьма интенсивным добавлением данных в realtime - и ничего, жили. А в многогиговой базе на орацле у нас по 20 минут выполняется только всякая аналитика, где запрос на четыре экрана мелким шрифтиком - да и то если кэш не прогрет. И никто там вручную rowid не собирает по битикам, что странно. Ну, правда, стоило это довольно дорого.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

39. Сообщение от пох. (?), 24-Янв-20, 10:55	+/–
> Лучше бы сборочную систему поправили она ж целиком вторична и делается на от..сь. Но если ты поправишь - полагаю, такой патч вполне примут. Только вот разбираться в том, что генерит эту сборочную систему - себе дороже, и гораздо проще не париться, задав дефайны - не так их и бесконечно много. P.S. соберешься править - сделай еще параметры для WAL и синхронной записи при нем - а то и их приходится вручную определять. Причем bsdшный мэйкфайл такому тоже не обучен. P.P.S. мне лень, у меня и так все работает, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

40. Сообщение от Аноним (40), 24-Янв-20, 12:28	+/–
lite тоже не значит легковесный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

41. Сообщение от Аноним (40), 24-Янв-20, 12:29	+/–
lite тоже не значит легковесный?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

42. Сообщение от Аноним (24), 24-Янв-20, 16:48	+/–
Тем, что нужно делать [mYear, mMonth, mDay, mHour, mMinute, mSecond] по шесть полей на одну дату (и то если повезло и они в UTC), а если дат несколько, то это просто какой-то кошмар их создавать. В целом конечно можно и с UnixTime немного погеммороиться, но было б удобнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #46

43. Сообщение от Аноним (24), 24-Янв-20, 16:50	+/–
А для meson как подпроект кто-то уже сделал версию для встраивания?
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от Alexey (??), 24-Янв-20, 21:50	+/–
По объему он все еще очень легкий
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

45. Сообщение от MBG (?), 25-Янв-20, 07:52	+2 +/–
Ну-ну, ври, да не завирайся (с) Если обосновать полезность и реализуемость фичи - сделают. Да, код напишут сами по лицензионным соображениям. В свое время я предложил добавить компрессию для расширения FTS - показал результаты тестов с компрессией и без, прислал свою реализацию для проверки. В итоге идею приняли и компрессию добавили. Так что если вы измеряете результат полезностью - все отлично, если же вам попиариться принятым в апстрим кодом - тогда вон в кде шлите, там имхо вообще все принимают (в качестве подтверждения можете нагуглить мою давнюю переписку с разработчиками akonadi).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #47

46. Сообщение от Q2W (?), 25-Янв-20, 11:42	+/–
С unixtime, имхо, будет достаточно удобно, если для преобразования даты/времени в unixtime и обратно юзать какую-нибудь либу. В остальном - это же sqLITE. Преимущество должно быть в т.ч. в простоте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #48

47. Сообщение от Аноним (31), 25-Янв-20, 13:00	+/–
у них mailing list без TLS. отказываюсь таким пользоваться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #49

48. Сообщение от MBG (?), 25-Янв-20, 17:59	+/–
Зачем? Еесть нативная поддержка, зачем юзать какую-то либу? Только чтобы не читать документацию?:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #51

49. Сообщение от MBG (?), 25-Янв-20, 18:02	+/–
Или крестик сними ими или трусы одень (с) нет проблем написать напрямую на почту DRH - не припомню случая, чтобы он мне не ответил. Ах да, попиариться не выйдет :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

50. Сообщение от KonstantinB (??), 25-Янв-20, 19:50	+/–
Чаще всего виртуальные столбцы используются для того, чтобы построить индекс по выражению. В постгресе это можно делать и напрямую
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

51. Сообщение от Q2W (?), 25-Янв-20, 22:31	+/–
Нет нативной поддержки, об том и тред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #52

52. Сообщение от MBG (?), 26-Янв-20, 08:51	+/–
Понял, «чукча не читатель, чукча писатель», в документацию религия не позволяет. Итак, смотрим https://www.sqlite.org/lang_datefunc.html Compute 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'); И так далее, еще много всего. Сразу добавлю, что функции эти существуют давно и надо было только документацию открыть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #53

53. Сообщение от пох. (?), 27-Янв-20, 10:27	+/–
это все же не тип данных DATE или DATETIME, это преобразования (впрочем, теперь вот их можно сложить в генерируемый столбец, только непонятно, для чего) Но, учитывая, что внутри самой sqlite существуют на самом деле только два типа данных - integer и string ;-) - совершенно непонятно, зачем эта имитация анониму.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

54. Сообщение от iZEN (ok), 27-Янв-20, 14:56	+/–
Этот релиз SQlite3-3.31.0 приводит к ошибке сегментации Thunderbird и Firefox - пришлось откатываться на предыдущую версию и восстанавливать профили пользователя.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема