2024 10 24 дайте мне sql
Дайте мне SQL
Вчера с @biozz_dev говорили про книжки. Ваня перекатился на Яндекс Книги, а я сейчас в процессе написания своего self-hosted аналога. Это типичная проблема в бизнесе “build vs buy”, нужно будет расписать. Сегодня речь пойдет о том, почему мне лично не нужен UI.
Был конец 80-х, и бородатые дядьки сели и решили, что надо придумать какой-то язык запросов к данным. Выглядит это всё для среднего человека сначала просто:
SELECT age, first_name, last_name
FROM users
ORDER BY created_at
А превращается это в какого-то монстра (https://neon.tech/postgresql/postgresql-tutorial/postgresql-cte#3-multiple-ctes-example), как только нужно что-то сложное. Зачем же оно нужно?
Потому что, когда вы пользуетесь продуктом, за вас уже порешали. И если раньше интернет был зелёным и приятным, и сортировка по цене означала сортировку по цене, то сейчас любой каталог/витрина/лента заполнена “умными” помощниками. Мы будем показывать не то, что вы просили, а то, что нам выгодно.
Дальше больше: внутреннее представление объекта, как правило, богаче, чем внешнее. Часто значимые вещи пихают в описание товаров, а не в характеристики, поэтому, разбираясь, можно поискать нужное. В случае базы данных можно сделать что-то типа ~ <мои любимые регулярные выражения>, а в случае сервиса вам никто ничего не гарантирует.
В итоге, разворачивая собственный сервис, можно подключиться к базе данных и сделать любой запрос. Например, подключить metabase и начать строить дашборды. Альтернативным вариантом при доступности API можно сваливать данные к себе через какой-то airflow, но этот метод уже менее гарантирован.
И люди этим сильно увлекаются: https://beepb00p.xyz/hpi.html или https://www.joshcanhelp.com/personal-data-pipeline/.
Не забываем про бекапы по схеме 3-2-1.
@chernov_sharit