https://gist.github.com/joelonsql/15b50b65ec343dce94db6249cfea8aaa

норм идея.
ровно до того момента, пока FK существует и его можно выбрать однозначно. потом придется переписывать все запросы…

​Итоги года говорят о том, что строить планы на год смысла не имеет. Все всегда идет не так :)

Поэтому всех с НГ, а рефлексировать буду в следующем году!

А вместо пожеланий вот вам нестареющая классика и картинка 10летней давности

Ну, типа, вот...

Snowflake is the DBMS of the Year 2021

Runner-up: PostgreSQL
Third place: MongoDB

https://db-engines.com/en/blog_post/93

Previous winners of the DB-Engines DBMS of the Year Award:

PostgreSQL 2020
MySQL 2019
PostgreSQL 2018
PostgreSQL 2017
Microsoft SQL Server 2016
Oracle 2015
MongoDB 2014
MongoDB 2013

Слышали про duckdb? Это такая OLAP версия SQLite здорового человека.
Казалось бы, куда большим и сложным монстрам до in-memory серверлеса, но тут clickhouse добавили duckdb в свой бенчмарк…

На всякий случай напомню, что существует clickhouse-local, который полноценный кликхаус, но локально на машине и без всяких кластеров и зукипепов.

​Алекс недавно у себя в канале написал пост, что все и так проклято, а люди web3 с метаверсами пилят.

Но все тут собравшиеся знают, что сингулярности не будет :)

Ну не будет и не будет, чего ворчать-то?

Мне тут просто музыкой навеяло...
В ближайшее время на parsers.dev и holistic.dev ожидается релиз mysql/mariadb.
И пока я писал AST-парсер и компилятор, я желал всех благ и здоровья товарищу Монти.

Почему-то постоянно вспоминал смешную статью "Узник замка Фаренгейт":
"Фаренгейту посчастливилось умереть достаточно давно. Будь он жив, к нему бы пришли люди, говорящие с акцентом и убили его арматурными прутьями"

Но это так...
Раздумывая о том какие правила анализатора надо написать в первую очередь, я наткнулся на кеширование запросов.
Нет, не планов запросов, а запросов. Прям побайтово.
Работало это так:
- ключом кеширования является целиком текст запроса. Прям вот с учетом регистра.
- в кеш сохраняется результат выполнения запроса и список таблиц, которые были использованы.
- если какая-то из таблиц обновилась, то кеш очищается.

Прям мем "we have food at home":
- мама, я хочу materialized view!
- materialized view есть у нас дома.
materialized дома: query cache

Там еще много всяких приколов с транзакциями, но это вообще-то и не особо удивительно.
Дальше я случайно наткнулся на кусок исходника, который за это дело отвечает:

https://github.com/twitter-forks/mysql/blob/master/sql/sql_cache.cc#L603

static bool has_no_cache_directive(char *sql)
{
  int i=0;
  while (sql[i] == ' ')
    ++i;
    
  if (my_toupper(system_charset_info, sql[i])    == 'S' &&
      my_toupper(system_charset_info, sql[i+1])  == 'Q' &&
      my_toupper(system_charset_info, sql[i+2])  == 'L' &&
      my_toupper(system_charset_info, sql[i+3])  == '_' &&
      my_toupper(system_charset_info, sql[i+4])  == 'N' &&
      my_toupper(system_charset_info, sql[i+5])  == 'O' &&
      my_toupper(system_charset_info, sql[i+6])  == '_' &&
      my_toupper(system_charset_info, sql[i+7])  == 'C' &&
      my_toupper(system_charset_info, sql[i+8])  == 'A' &&
      my_toupper(system_charset_info, sql[i+9])  == 'C' &&
      my_toupper(system_charset_info, sql[i+10]) == 'H' &&
      my_toupper(system_charset_info, sql[i+11]) == 'E' &&
      my_toupper(system_charset_info, sql[i+12]) == ' ')
    return TRUE;
  
  return FALSE;       
}

https://github.com/twitter-forks/mysql/blob/master/sql/sql_cache.cc#L1490

if ((my_toupper(system_charset_info, sql[i])     != 'S' ||
      my_toupper(system_charset_info, sql[i + 1]) != 'E' ||
      my_toupper(system_charset_info, sql[i + 2]) != 'L') &&
    sql[i] != '/')
{
  DBUG_PRINT("qcache", ("The statement is not a SELECT; Not cached"));
  goto err;
}

На этом, как говорится, мои полномочия все...
А "Узник замка Фаренгейт" вы прочитайте. Смешное.

не все полимеры еще пролюблены…

зачем нужны типы, если string уже придумали

В postgresql 15 (да, осенью будет уже 15 версия, обновитесь уже с вашей 9.6) будут json логи.
нунаканецта! :)

https://www.depesz.com/2022/01/17/waiting-for-postgresql-15-introduce-log_destinationjsonlog/

​Завидую (нет) упорству тех товарищей, которые уверены, что можно написать универсальный парсер (и компилятор) для разных диалектов SQL.

Нет, ну, парсеры бывают разные. Например, парсеры для подсветки синтаксиса: распознаем все знакомые токены и раскрашиваем их в разные цвета.

Следующий этап - распознать похожие на подходящие токены в нужных местах запроса. Тут довольно часто тоже можно срезать углы, но только если у вас нет в планах компилятора или какого-нибудь intellisense.
Внезапно различия начинаются прямо на этапе описания идентификаторов.

В Postgresql имена таблиц и колонок можно записать как table1, Table1 и "Table1". Первые два будут приведены к одному виду (в нижний регистр), а для обращения к последнему нужно будет и дальше брать в кавычки и соблюдать регистр. Одинарные кавычки будут ошибкой.

В Snowflake table1 и Table1 будут приведены к верхнему регистру, для регистрозависимого имени нужно будет так же указать имя в двойных кавычках.
Можно еще задать имя в обратный одинарных кавычках - `table1`. Оно приведется к верхнему регистру, а кавычки останутся частью имени.

В Mysql table1 и Table1 будут РАЗНЫМИ объектами, а `table1` будет равен table1. Одинарные и двойные кавычки будут ошибкой.
Да, еще в Mysql можно начинать имя с $, нигде такого безобразия нет.

В Postgresql и Mysql имена объектов можно указывать не только латинскими буквами, но и кириллическими.
А в Snowflake нет.

Но зато там есть такая конструкция как identifier:

create table identifier($my_table_name) (i integer);
select * from identifier($my_table_name);

И режим nighmare - валидирующий парсер.
Это когда синтаксис будет распознан как невалидный по тем же правилам, что и в целевой базе.
Здесь появляются отдельные списки токенов, которые нельзя использовать. Причем, нельзя не везде :)

Например, в Snowflake ключевое слово LIMIT - не ключевое слово и его можно использовать как алиас. Во всех базах такое не пройдет:

select * from t as limit limit 1

А в Snowflake все ок.

Еще есть отдельный список того, что нельзя использовать в качестве имен таблиц.
Отдельный список того, что нельзя использовать в качестве имен колонок.
Но не всегда. Иногда можно.

Например, в Snowflake CONSTRAINT может быть именем поля, но только в кавычках. А CURRENT_DATE не может даже в кавычках.
Но это имена полей. Именами таблиц и то и то может быть даже без кавычек...

А в Mysql можно ключевые слова использовать как имена полей, если взять их в обратные кавычки:

create table t(`limit` integer);

Но в запросе

select limit from t;

так нельзя, а так

select t.limit from t;

уже можно :)

В Postgresql и Snowflake можно и так и так...



С компиляторами, кстати, тоже отличная история.
В Snowflake и Clickhouse можно переиспользовать алиасы в рантайме:

 select 1 as a, a + 1 as b  

а в Postgresql и Mysql нет.

Mysql важно в каком регистре написаны имена таблиц, но на колонки в этом случае почему-то наплевать: table1.field1 и table1.Field1 это одно и то же.
Очень удобно.


Неименованные динамические колонки так же работают по-разному:

select 1+2
-3 + 'a'

В Postgresql все колонки без имени будут назваться '?column?'
В Mysql и Snowflake будет взят исходный код запроса, в нем заменены все переносы строк на пробелы и все приведено к соответствующему регистру - в Mysql к нижнему, в Snowflake к верхнему и будет выглядеть как "1+2 -3 + 'a'"


"Зачем, ты дед, втираешь нам какую-то дичь?", - спросите вы. А я вам скажу. Будьте зайками, не используйте в именах объектов ключевые слова языка. И кавычки тоже.
Это сэкономит много часов дебага.

В holistic.dev, кстати, есть правило, которое вам на это укажет! (playground)

PS: всем кто не любит js, но любит mysql: там строки в математических операциях молча кастятся к нулю.
И делить на 0 можно. NULL получается.
Ладно хоть NULL = NULL это NULL, а не true...

Вышла новая бесплатная книга от postgrespro по внутренностям PostgreSQL

https://postgrespro.ru/education/books/internals

127 окон хватит всем! :)

По мотивам истории с faker.js заметка злого фронтенда про гугл шрифты:

https://news.1rj.ru/str/angry_front_end/20

Пришло письмо от PGConf.Russia
В этом году будет проходить 28 февраля – 01 марта.

Программы пока нет, ждут доклады.

https://pgconf.ru/2022

Комрадс, свершилось!
Начинаю искать сотрудников в holistic.dev

Работать работу. Оплата деньгами.

Прямо сейчас нужны js'еры, кто умеет в типы (ts/flow) и знает про SQL.
Сначала писать будем правила для анализатора.

Т.е. никаких крудов и перекладывания жсонов (хотя, блин, как посмотреть).

Не-js'ры, желающие влиться в наш молодой (кхе-кхе) дедовский коллектив, тоже вэлкам, бэклог на 5 лет вперед, работа найдется :)
Так же нужен будет техпис, который знает про SQL.

Пишите мне в личку @antonrevyako

Помни, лайк и шер повышает стрит кридабилити! :)

Крутейшая новость для тех, кто любит читать пейперы (а именно препринты на arXiv). Если в ссылке на abstract статьи заменить "arxiv" на "ar5iv", то можно читать статью в виде веб-страницы. Тут больше деталей - https://twitter.com/dginev/status/1488157927001268231

Примеры статей:

https://arxiv.org/html/1504.00204 → https://ar5iv.org/html/1504.00204
https://arxiv.org/html/2102.02527 → https://ar5iv.org/html/2102.02527