Все выпуски SQL-TIL:

1) https://news.1rj.ru/str/nosingularity/535
2) https://news.1rj.ru/str/nosingularity/541
3) https://news.1rj.ru/str/nosingularity/548
4) https://news.1rj.ru/str/nosingularity/572
5) (snowflake) https://news.1rj.ru/str/nosingularity/582

​В этом довольно специфичном тесте PostgreSQL выносит MSSQL и MySQL вперед ногами:


https://www.mssqltips.com/sqlservertip/6607/delete-sql-performance-for-sql-server-mysql-and-postgresql/

Ребята из @profunctor_io большие молодцы и я всегда готов поддержать их призывы рассказать про профунктор-джоб, поэтому вот:

Не секрет, что лучшие вакансии в айти расходятся задолго до попадания на hh и linkedin. Одно из мест где можно ловить такие варианты это канал Профунктора: NVIDIA, Revolut, Bolt, Мосбиржа и другие лучшие карьерные варианты для разработчиков появляются там регулярно. Стоит подписаться, чтобы быть в курсе того сколько нынче платят «по рынку», и не гнуть спину за полцены из-за того что неудачно прособеседовался год назад.

@profunctor_jobs

Андрюха, у нас пхп, возможно битрикс, по коням!

И первая хорошая новость за этот год:


https://www.government.is/news/article/2020/10/27/-Foreign-experts-can-work-remotely-in-Iceland/

​Не перестаю кекать со snowflakeDB (вот тут история, как я грамматику по документации начал писать)

Как можно одновременно выполнить запрос и выдать "SQL compilation error"?

Update: причем ошибка вываливается на примере из документации. А результат, который все-таки прилетает, не совпадает с результатом из документации...

PS: про сноуфлейк нет мемасов, поэтому вот вам демотиватор (!!!):

BORING!

​Прошло несколько месяцев с публикации прошлой версии подборки экзотических применений SQL, поэтому не грех опубликовать ее еще раз, добавив еще один пункт.

Не все знают, но SQL можно использовать не только для работы с данными в БД.
Есть возможность манипулировать данными из командной строки.
Зачем такое может понадобиться?

1) Парсинг JSON-логов
https://github.com/avz/jl-sql
Можно придумать много хороших usecases. Я писал про эту тулзу в статье про тестирование логов - https://news.1rj.ru/str/nosingularity/198

> cat data.json | jl-sql 'SELECT key, SUM(value) AS sum, COUNT(*) AS count GROUP BY key'

2) Работа с параметрами операционной системы
https://osquery.io/
Совершенно безумная и красивая идея. 257 источников данных!

> osqueryi --json "SELECT * FROM mounts m, disk_encryption d WHERE m.device_alias = d.name AND d.encrypted = 0;"

3) Работа с изображениями
https://github.com/escherize/img_sql/

> ./img_sql.py -i samples/matrix.jpg -o samples/matrix_out.jpg -s 'update pixels set r = g, b = r, g = b where x > 700'

Осталось написать транспайлер в GLSL и будет win :)

4) SQL для MongoDB, DynamoDB, Kafka, S3
Если не хочется работать с монгой, но очень нужно, то можно выкрутиться так
https://rockset.com/solutions/mongodb/

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

5) SQL для запросов по git репозиториям
https://github.com/augmentable-dev/gitqlite (переименовали в askgit)

> -- how many commits have been authored by user@email.com?
> SELECT count(*) FROM commits WHERE author_email = 'user@email.com'

6) Играем музыку оО
https://relational-pipes.globalcode.info/v_0/examples-jack-midi-generating-1.xhtml

А вы тут спрашиваете, зачем я по snowflake упарываюсь...

https://twitter.com/dbengines/status/1322913553590996994

​Не было ни одного случая, чтобы мне не было больно от контакта с интерфейсами продуктов гугла.
Не бомбит только от gmail, да и то, это скорее всего стокгольмский синдром.

Каждый раз, когда появляется необходимость зайти в гугл аналитику или в G Suite, я стараюсь максимально отпрокрастинировать это действие. Потому что знаю, что потрачу в 10 раз больше времени, чем мог бы, и все равно все будет через одно место. И при этом, скорее всего, я не получу того, что мне было нужно, а просто забью.

Почему в аналитике статистика с задержкой в сутки? Виноват часовой пояс? Гуглим... 15 минут спустя находим как настроить часовой пояс для сайта. Проверяем: 10 кликов по менюшкам... Нет, все ок. Часовой пояс подходящий. Так, допустим, аналитика приезжает с задержкой. Гуглим... "Статистика (например, по кликам, конверсиям и показам), как правило, появляется с задержкой примерно в три часа". Ну допустим, но статы нет... А, ладно, хрен с ним, не больно и хотелось...

И так каждый раз! Сцк!

И грузится это все как будто сервера в секретном бункере под горой в Швейцарии, куда протянули только ADSL, а я через TOR захожу.

​я: что-то я не высыпаюсь...
wakatime: на этой неделе ты писал код 50 часов

PS: wakatime считает сколько ты нажимаешь на кнопки в IDE, если не ставить отдельные плагины для браузера и терминала. у меня стоят в vscode и datagrip. Т.е. сколько я гуглил и смотрел ютубчик тут не посчитано.

​Нашел где примененить слово "кринж":

haskell на js:

https://github.com/stevekrouse/hs.js

Саундтрек для дедов на выходных:

https://www.youtube.com/watch?v=nIrJGWohli0

​Пятничный SQL-WTF
Понедельничный SQL-TIL #6

Последние недели я с головой погружен в написание парсера для SnowflakeDB и все SQL-WTF касаются именно этой базы. Я понимаю, что эта база в русскоязычном сегменте интернета мало кого интересует, но других вотсдефаков у меня для вас нет :)

1) LIMIT - не ключевое слово
Источникам данных и колонкам можно задавать псевдонимы:

SELECT t.* FROM table1 AS t

или без AS

SELECT t.* FROM table1 t

Но на этом запросы обычно не заканчиваются. После списка источников данных может идти union, where, group by, having, order by.
Ни одно из этих ключевых слов не может быть использовано в качестве псевдонима. Кроме LIMIT:

SELECT limit.* FROM table1 limit LIMIT 10

2) Неявное именование подзапросов
Если в качестве источника данных используется подзапрос, для него должен быть задан псевдоним. Так работает в PostgreSQL, так работает в MySQL:

SELECT * FROM (SELECT * FROM table1) t

Но в SnowflakeDB это совершенно необязательно. Так же как и в SQLite... :)
Но что будет, если у нас два подзапроса?

SELECT * FROM (SELECT * FROM table1), (SELECT * FROM table1)

В SQLite будет магия - CROSS JOIN с колонками только из первой таблицы... Но, справедливости ради в SQLite даже с заданными псевдонимами и прописанным CROSS JOIN будет такой же результат... B как выяснилось, там нет RIGHT JOIN и FULL JOIN... Пользуясь случаям - привет всем фанатам этой базы :)
Но черт с SQLite, что там у SnowflakeDB?

> SQL compilation error: duplicate alias 'values'

Чего? Какой values?
Оказывается, что SnowflakeDB сам дописывает один и тот же псевдоним к каждому подзапросу:

SELECT values.* FROM (SELECT * FROM table1)

3) Нестрогие значения параметров
В SnowflakeDB есть такая функция для работы с датой:

SELECT  next_day(current_date(), 'Friday')

которая вернет дату следующей пятницы. Удобно. Молодцы. Но:

SELECT  next_day(current_date(), 'Friday I am in love')

даст такой же результат.
Как минимум, неплохо бы было описать это поведение в документации.

4) ISO? Какой ISO?
Правила сортировки (сollation) описываются в формате language[_country][-specifier ...]
И все бы было ок - возьми ISO639-1 для языков, ISO3166-1 для стран. Да, но кого интересуют эти мелочи?

SELECT 'foo' COLLATE 'trololo'

Как я об этом узнал? Случайно, потратив час на поиск того, как узнать доступный список collation.

----

Есть версия, что все эти странности связаны с тем, что основные пользователи SnowflakeDB - дата аналитики и грузить их всякими мелочами типа правильного названия стран и языков это лишнее. Мне сложно сказать что-то по этому поводу, но тем, кто перейдет на SnowflakeDB с мейнстрим баз, гарантированно будет некоторое время больно.
И уже сейчас понятно сколько невалидных отчетов из-за этого было построено, but who cares?

Сразу два ведущих венчурных фонда: Sequoia Capital и Greylock, инвестировали $40M в ходе раунда B в компанию-лидера в области облачной аналитики Rockset. Общая сумма инвестиций составила $61.5M.

https://www.globenewswire.com/news-release/2020/10/27/2115067/0/en/Rockset-Raises-40-Million-For-Real-Time-Analytics-at-Cloud-Scale.html

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

Из заявленных  на сайте параметров:
1/ задержка данных - в пределах секунды после создания записи;
2/ поддержка быстрых, высококонкурентных запросов - быстрее в 125 раз, чем SQL;
3/ в 15 раз меньше затрат на операционную поддержку, в сравнении с Elastic или Druid.

Компания Rockset наблюдает феноменальный рост, поскольку аналитика, полученная в реальном времени, становится решающим фактором успеха для организаций произвольного размера. В последнем квартале выручка Rockset выросла на 290%, в проекте зарегистрировались тысячи новых пользователей, а число запросов, выполняемых на платформе, выросло на 313%.

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

Привлеченные средства компания направит на рост команды, ускорение инноваций продуктов и усилия по выводу их на рынок.

Сильное заявление. Проверять я его, конечно, не буду...