There will be no singularity
1.99K subscribers
249 photos
15 videos
5 files
996 links
Smartface, technologies and decay
@antonrevyako
Download Telegram
В мою подборку необычных применений SQL добавился еще один тул для git

askgit:
SELECT count(*) FROM commits WHERE author_email = '[email protected]'
Очередная история успеха приложения на рельсах.
На этот раз у гитлаба
https://about.gitlab.com/blog/2021/09/29/why-we-spent-the-last-month-eliminating-postgresql-subtransactions/

Они месяц с недешевыми консультантами разгребали то, что им нагенерили рельсы. Причем приключение случилось в 4 строках кода.

Может быть вы помните статью dhh, что рельсы им стоят "всего" $450k в год, но зато какой кайф не писать этот богомерзкий SQL.
Это он посчитал только сколько им стоит лишнее железо.

Если решите повторить расчеты для своего ror-проекта, то закладывайте еще работу DBA из расчета где-то $500/час.

Я, честно говоря, не хотел акцентировать внимание на этой истории, потому что, ну а что вы, собственно, хотели от ror.
Но в твиттере CEO Fivetran напомнил о ней с каментом "нахер эти ORM", а дальше все как в тумане...
Отличный мини сериал о том, как корпорация добра придумала отличную схему, позволившую кинуть множество небольших компаний по всему миру и в частности одну небольшую немецкую компанию, создавшую Terravision - прародителя google earth из 1994 года.

https://www.netflix.com/ru-en/title/81074012
Там как минимум не хватает аналитических баз... И если вы вдруг пропустили, s3 теперь тоже считается базой...
В блоге Wix(это такой конструктор веб сайтов) рассказали какие базы они используют в каких частях проекта, плюс добавили свой взгляд на минусы и плюсы баз для разных кейсов. Немного поверхностно для такой обширной темы, но для общего понимания ок.

https://medium.com/wix-engineering/5-database-technologies-used-by-2000-wix-microservices-e4769638b8c3
Любите ли вы питон, как люблю его я...
К вопросу о "сделать плохо, но быстро" VS "сделать круто, но за год"

Я всегда был за первое, "из говна и палок, но вчера". А потом понял, что, во-первых, мне наверное везло с коллегами - которые могли и быстро, и без откровенного шлака. А во-вторых вспомнил про GST - "Google Standard Time".

Все сервера гугла работают в часовом поясе Pacific Time. Сколько у них серверов в разных концах света, миллионы? И на всех - калифорнийское время. В логах, в базах, в новостных лентах все хранится в PST. Даже в BigQuery если написать new Date() будет, сука, PST. Когда-то в самом начале делали "быстро" и решили забить, а теперь чинить настолько сложно и стремно, что проще оставить как есть.

Кто-то в шутку решил назвать "Google Standard Time". Так и прижилось.
Подведем итог ^
В mysql при inline-объявлении внешнего ключа в CREATE TABLE, никакой FK не создается и сослаться можно на любые колонки, даже не имеющие unique констрейнта!

create table b (id int references a(id));


И это поведение не зависит от движка таблицы. При дампе DDL это свойство не будет отображено.

Создать внешний ключ можно только для движков innodb и ndb одним из 2 способов:

create table c (id int, constraint foreign key (id) references a(id));

или

alter table b add foreign key (id) references a(id);
Функциональщина в SQL by timescale:

SELECT device_id, 
timevector(ts, val) -> sort() -> delta() -> abs() -> sum()
as volatility
FROM measurements
WHERE ts >= now()-'1 day'::interval
GROUP BY device_id;


https://blog.timescale.com/blog/function-pipelines-building-functional-programming-into-postgresql-using-custom-operators/