1.1, Аноним (1), 11:31, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> Добавлена поддержка генерируемых столбцов (вычисляемых столбцов), позволяющих при создании таблицы создать столбец, значение которого автоматически вычисляется на основе содержимого другого столбца.
Знатоки, объясните: чем представления (view) хуже? Или я не понял и это вообще про другое?
| |
|
2.4, Аноним (4), 11:42, 23/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя. Ну ещё все данные и их производные в одной таблице, не нужно писать в одну и читать из другой как это будет с view.
| |
|
3.12, Аноним (12), 12:56, 23/01/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
>эту штуку можно не вычислять каждый раз, записав её на диск
А от VIRTUAL тогда чем?
| |
|
4.14, Аноним (14), 13:00, 23/01/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Тем, что не надо каждый раз выражение писать в select. Или делать отдельный view.
| |
|
3.13, Аноним (14), 12:59, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Основное отличие в том, что эту штуку можно не вычислять каждый раз, записав её на диск. А с view так нельзя.
В "больших" СУБД есть materialized view, тоже можно не вычислять каждый раз. Надеюсь, сабжевая фича является частью плана по их включению в SQLite.
| |
|
2.22, Аноним (22), 13:23, 23/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
VIEW, например, в постгресе - кошмарная и вредная конструкция, не дающая менять схему нижележащих таблиц, а для MATERIALIZED либо требующая блокировки, либо создающая кучу других проблем (в случае REFRESH CONCURRENTLY). Всё что угодно лучше этой гадости - функции, триггеры, обычные таблицы обновляемые запросом, CTE, в зависимости от того что применимо. Почему бы также и не вычисляемые столбцы, хотя по мне так их сфера применения тоже очень сильно ограничена (в основном обратной совместимостью).
| |
|
3.30, Аноним (30), 21:01, 23/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
С MV и в оракле тяжко, если много данных и обновление таблиц частое.
| |
3.50, KonstantinB (??), 19:50, 25/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Чаще всего виртуальные столбцы используются для того, чтобы построить индекс по выражению.
В постгресе это можно делать и напрямую
| |
|
|
1.2, Аноним (2), 11:36, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Наверное прикольно. Но когда включат поддержку icu? что бы запрос Select "Ы" like "ы" выдавал 1?
известный баг\фича))
| |
|
2.5, Аноним (5), 12:04, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Раз не включают по умолчанию значит это никому не нужно. А полтора землекопа могут и сами себе с ICU собрать.
| |
2.7, пох. (?), 12:07, 23/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Если он начнет такое выдавать - да, это будет именно баг, поэтому ответ - никогда.
А поддержка upper/lower - существует, но, поскольку это embedded db, collate function ты ей должен предоставить сам - https://sqlite.org/c3ref/create_collation.html - можешь себе "включить поддержку icu", если умеешь.
Для "неумеющих кодить" существует postgres.
| |
|
3.20, Аноним (14), 13:15, 23/01/2020 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Для "неумеющих кодить" существует postgres.
Домино — это вам не шахматы, тут думать надо.
| |
|
|
3.26, Аноним (26), 17:57, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
это не та поддержка, которую хочет аноним (если мы правильно понимаем его пример - он, вероятно, хотел все же не безусловно и во всех случаях чтобы Ы было like ы, а работающий collation ?)
Это поддержка в cli, без которой предложенную им строку вообще набрать, скорее всего, не получится.
| |
|
2.36, Аноним (36), 02:08, 24/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Никогда, в SQL like --- _регистрозависимый_.
Для поиска независимо от регистра используют UPPER/LOWER или бывает делают ilike, но ilike нет в стандарте SQL, это расширение на усмотрение авторов СУБД.
| |
|
1.3, PavloT (?), 11:42, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Просто удобство. Не всегда хочется создавать отдельную сущность в виде view. В принципе можно и запросом разрулить.
| |
|
2.6, Аноним (5), 12:05, 23/01/2020 [^] [^^] [^^^] [ответить]
| –7 +/– |
Имхо творят сущностный для видимости деятельности. Ничем хорошим это обычно не заканчивается.
| |
|
3.16, Аноним (14), 13:01, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Полагаю, в этом случае закончится поддержкой materialized views, что неплохо.
| |
|
|
1.8, Аноним (8), 12:14, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
SQLite - хороший, годный продукт. Но кажется легковесность потихоньку улетучивается.
| |
|
2.9, пох. (?), 12:27, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
embedded db не обязана быть "легковесной", ей надо быть - embeddable.
А дальше, в случае sqlite все зависит от тебя - часть фич включается только по запросу, часть можно отключить. Но для этого его надо пересобирать, причем в некоторых случаях - из исходников.
Нет, sqlite-autoconf-3310000.tar.gz - это не исходник, и конфигурируется там не всё.
| |
|
1.11, ыы (?), 12:55, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
бизнес-логика встраиваемая прямо в таблицы... каша будет...
| |
|
|
3.18, ыы (?), 13:04, 23/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Да, есть такие любители - выдать толпе мыло, веревку и посмотреть что получится в итоге...
а получится как в расте (недавно), получится как в вордпрессе (перманентно)
| |
|
4.19, Аноним (14), 13:13, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
В расте получился способ ускорить работу, отключая всякие проверки. В результате можно догнать по производительности такие языки, как C и C++.
> получится как в вордпрессе (перманентно)
Если вас беспокоит безопасность — не пользуйтесь вордпрессом.
| |
|
5.21, ыы (?), 13:16, 23/01/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
У вас на все есть ответ :)
а как потом выгружить такие столбцы для переноса в другую базу? mysql например?
| |
|
6.23, Аноним (22), 13:29, 23/01/2020 [^] [^^] [^^^] [ответить]
| +4 +/– |
Также как из MySQL выгружать в PostgreSQL, а из оного - в Oracle, а оттуда в Redis. т.е. со всей логикой ровно никак - это разные базы с разными фичами, не прозрачно взаимозаменяемы и не должны такими быть. А если только данные, то брать и выгружать, и вычисляемые столбцы в этом только помогают, потому что помогают обеспечить совместимость и прозрачную конвертацию схемы. Собственно, никакую другую сложную бизнес логику в них и не запихнуть.
| |
6.25, Аноним (14), 16:50, 23/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> У вас на все есть ответ :)
Нас, анонимов, много. Хоть кто-нибудь, да ответит.
> а как потом выгружить такие столбцы для переноса в другую базу? mysql например?
Почему бы вам не спросить, как переносить из MySQL в SQLite пользователей и их права доступа, например?
| |
|
|
|
|
|
1.24, Аноним (24), 16:46, 23/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.
Не понял, что с UUID можно ли делать PK поле с UUID? Можно ли его генрить автоматический и получать на INSERT?
Будет ли когда нибудь обратный индекс для текста?
| |
|
|
3.42, Аноним (24), 16:48, 24/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Тем, что нужно делать [mYear, mMonth, mDay, mHour, mMinute, mSecond] по шесть полей на одну дату (и то если повезло и они в UTC), а если дат несколько, то это просто какой-то кошмар их создавать.
В целом конечно можно и с UnixTime немного погеммороиться, но было б удобнее.
| |
|
4.46, Q2W (?), 11:42, 25/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
С unixtime, имхо, будет достаточно удобно, если для преобразования даты/времени в unixtime и обратно юзать какую-нибудь либу.
В остальном - это же sqLITE. Преимущество должно быть в т.ч. в простоте.
| |
|
5.48, MBG (?), 17:59, 25/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Зачем? Еесть нативная поддержка, зачем юзать какую-то либу? Только чтобы не читать документацию?:)
| |
|
|
7.52, MBG (?), 08:51, 26/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Понял, «чукча не читатель, чукча писатель», в документацию религия не позволяет. Итак, смотрим 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');
И так далее, еще много всего.
Сразу добавлю, что функции эти существуют давно и надо было только документацию открыть.
| |
|
8.53, пох. (?), 10:27, 27/01/2020 [^] [^^] [^^^] [ответить] | +/– | это все же не тип данных DATE или DATETIME, это преобразования впрочем, теперь ... текст свёрнут, показать | |
|
|
|
|
|
|
2.31, Аноним (31), 21:13, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>Подскажите, что там с внедрением столбцов с типом DATETIME, DATE, TIME? Хочу искать по индексу по таким полям.
Не будет. Есть integer. Если нужно искать только по времени, и времена уникальны, то кодируешь в число и засовываешь в integer primary key, будет сверхбыстрый поиск, ибо integer primary key идёт в rowid.
Если нужно искать по нескольким primary, то прикидываешь сколько бит нужно на каждый primary нужно и кодируешь всё в один rowid с помощью битовых операций. Поиск будет нормальный, нужно просто правильно запрос синтезировать. Единственный недостаток - слишком много надо ручками делать. Давно бы запилил то что нужно, но там PR принципиально не принимают, а значит любой вклад в эту базу - это зря потраченный труд и время.
| |
|
3.32, пох. (?), 21:33, 23/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?
Обязательно заниматься неведомой херней?
Правильно они такие PR не принимают - эта проблема в голове у оверинжинирнутого разработчика, а не в софте, который вполне последовательно реализует sql, а не костыли.
| |
|
4.35, Аноним (31), 01:31, 24/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
>индекс-то создать по стольким полям, сколько нужно, и не лезть в rowid - коран не велит?
любые индексы будут медленнее rowida. Их ещё добавлять и удалять надо, ибо со включёнными индексам вставки будут очень медленные. rowid же используется самой базой и связан с низкоуровневым представлением на HDD, поэтому последовательный доступ и поиск при кодировании в rowid будет быстрым.
Если у вас база в ведроприложении на несколько мегабайт, то вам пофиг. Если у вас многогоговая база на жёстких дисках, то вам не пофиг, будут импортироваться в неё данные неделю или 2 недели и будет 1 запрос идти минуту или 20 минут.
| |
|
5.38, пох. (?), 10:49, 24/01/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
если у вас "многогиговая база на жестких дисках" не может работать банально с индексами потому что "вставки очень медленные", и вы вынуждены заниматься наколеночной "оптимизацией" с ручным складыванием битиков - вы что-то уже понапроектировали явно не то. Может вам вообще не нужен был sql (вручную битики перекладывать - вообще не то, для чего его задумали)?
Возможно, именно sqlite для этого применения не очень подходил, хотя видел я немногогиговые (5-8 это ведь немного?) базы аж с FTS и весьма интенсивным добавлением данных в realtime - и ничего, жили.
А в многогиговой базе на орацле у нас по 20 минут выполняется только всякая аналитика, где запрос на четыре экрана мелким шрифтиком - да и то если кэш не прогрет. И никто там вручную rowid не собирает по битикам, что странно. Ну, правда, стоило это довольно дорого.
| |
|
|
3.45, MBG (?), 07:52, 25/01/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ну-ну, ври, да не завирайся (с) Если обосновать полезность и реализуемость фичи - сделают. Да, код напишут сами по лицензионным соображениям. В свое время я предложил добавить компрессию для расширения FTS - показал результаты тестов с компрессией и без, прислал свою реализацию для проверки. В итоге идею приняли и компрессию добавили. Так что если вы измеряете результат полезностью - все отлично, если же вам попиариться принятым в апстрим кодом - тогда вон в кде шлите, там имхо вообще все принимают (в качестве подтверждения можете нагуглить мою давнюю переписку с разработчиками akonadi).
| |
|
|
5.49, MBG (?), 18:02, 25/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
Или крестик сними ими или трусы одень (с) нет проблем написать напрямую на почту DRH - не припомню случая, чтобы он мне не ответил. Ах да, попиариться не выйдет :)
| |
|
|
|
|
|
2.37, Аноним (37), 08:21, 24/01/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Тоже думаю что def это не простые фаилы если вы сможете собрать именно с этими дефами https://github.com/Griggorii/wine_d3d_def_source ваин то вот и напишите мне на почту гмаил ком ник тот же.
Считаю что есть такие инструменты программирования которые ты считаешь мусором потому что просто не знаешь как применять.
| |
2.39, пох. (?), 10:55, 24/01/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Лучше бы сборочную систему поправили
она ж целиком вторична и делается на от..сь.
Но если ты поправишь - полагаю, такой патч вполне примут. Только вот разбираться в том, что генерит эту сборочную систему - себе дороже, и гораздо проще не париться, задав дефайны - не так их и бесконечно много.
P.S. соберешься править - сделай еще параметры для WAL и синхронной записи при нем - а то и их приходится вручную определять. Причем bsdшный мэйкфайл такому тоже не обучен.
P.P.S. мне лень, у меня и так все работает, да.
| |
|
1.54, iZEN (ok), 14:56, 27/01/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Этот релиз SQlite3-3.31.0 приводит к ошибке сегментации Thunderbird и Firefox - пришлось откатываться на предыдущую версию и восстанавливать профили пользователя.
| |
|