| 23:00:04 |
Umputun U |
шутка юмора?
|
| 23:00:24 |
Grigory Bakunov |
нет. там реально когда нет стрима -ЯРКО БЕЛАЯ страница
|
| 23:00:50 |
aleks ko |
унца тихо
|
| 23:02:16 |
Anton Kuznetsov |
еее, унца красиво теперь)
|
| 23:02:17 |
aleks ko |
норм
|
| 23:02:39 |
Роман Никишин |
В F12 посмотри что там сервер отвечает
|
| 23:02:53 |
Mikhail |
о, круто первый раз онлайн, давайте про DDD и EventStorming, пробовал кто-нибудь эту магию?
|
| 23:02:55 |
Anton Kuznetsov |
и почини?
|
| 23:03:16 |
Grigory Bakunov |
я прошу прощения, что такое f12?
|
| 23:03:30 |
Magic |
dev tools на винде же
|
| 23:03:41 |
Grigory Bakunov |
у меня и кнопка другая и винды нет
|
| 23:04:20 |
Роман Никишин |
Прикольно, что на макоси открыл случайно хоткей её запуска как кмд-шифт-с
|
| 23:04:39 |
Anton Kuznetsov |
cmd+option+i
|
| 23:04:40 |
RumS |
Тишина же в эфире?
|
| 23:04:54 |
Magic |
Мне казалось что кмд+опт+i по умолчанию
|
| 23:05:27 |
RumS |
В фф да
|
| 23:05:38 |
Aleksandr Mikheev |
denied: <html><body><h1>403 Forbidden</h1>
|
| 23:05:50 |
Anton Kuznetsov |
ровно как и в Chrome
|
| 23:06:11 |
Роман Никишин |
В каком браузере?
У меня Эдж для джиры и конфы. Там как раз идеально не растопыриявая пальцы комманд-шифт-С
|
| 23:06:45 |
Magic |
Может быть да, это от ФФ у меня в голове осталось
|
| 23:07:08 |
Mikhail |
когда?
|
| 23:07:08 |
radio-t bot |
каждую субботу, 20:00 UTC
Начался 7мин 8сек назад.
Скорее всего еще идет.
Следующий через 6дн 23ч 52мин 51сек
|
| 23:07:16 |
Grigory Bakunov |
дада, начался уже!
|
| 23:07:20 |
Grigory Bakunov |
вы просто не заметили!
|
| 23:07:45 |
Victor Osipov |
Ну да ну да
|
| 23:08:09 |
Mikhail |
тему бобук прикольную выбрал
|
| 23:08:38 |
Vladimir Stishkin |
|
| 23:08:40 |
Eugene Krokhalev |
Можно пока финал лиги чемпионов обсудить
|
| 23:09:10 |
Mikhail |
семь бед один резет
|
| 23:09:11 |
Роман Никишин |
Кстати, в сафари кмд-альт-i робит
|
| 23:09:14 |
Eugene Krokhalev |
Наверняка Леха пока футбол не закончится не появится
|
| 23:09:45 |
Глеб Панков |
А уже рассказали историю про программиста?
|
| 23:11:34 |
Роман Никишин |
Это где десять миллионеров пытаются бегать по полю?
|
| 23:11:58 |
Maksym |
Не занадто гучно музика на фоні?
|
| 23:12:59 |
Egor Miasnikov |
норм
|
| 23:13:38 |
Роман Никишин |
Ну, на пару дБ можно и приглушить было бы
|
| 23:14:14 |
Dark side |
минимум вдвое больше
|
| 23:14:31 |
Роман Никишин |
Самый класссный футбол у финнов, они там по колено в болоте пытаются хоть как то ходить и колбасками катаются
|
| 23:14:47 |
Alexey Nesterov |
Я как главный футболист?
|
| 23:14:56 |
Dmitry |
Играют то в Англии на Уемли.
А Алексей не в курсе
|
| 23:14:56 |
ㅤM ㅤ |
что-то со звуком или что? как будто все трое одновременно говорят. как-то друг на друга накладывается звук
|
| 23:14:58 |
Egor Miasnikov |
так может голоса побольше?
|
| 23:15:00 |
Aleksandr Mikheev |
Вообще это хоккей, но кто разбирается
|
| 23:15:08 |
Eugene Krokhalev |
финал ЛЧ сегодня в Лондоне
|
| 23:15:14 |
Victor Osipov |
Подкаст про вилки и ручки
|
| 23:15:26 |
Eugene Krokhalev |
Леха если бы увлекался, мог бы в живую посмотреть
|
| 23:15:45 |
Ivan Vinogradov |
Видимо путали и забивали вниз, поэтому сделали буквой T
|
| 23:15:46 |
Aleksandr Mikheev |
Он же не один из 20 миллионеров
|
| 23:16:06 |
Роман Никишин |
В Яндекс картинках по запросу футбол на болотах прям красотища в выводе
|
| 23:16:28 |
Eugene Krokhalev |
а я, кстати, думаю, что Леха уже миллионер
|
| 23:17:00 |
Роман Никишин |
Бегал бы по полю за колобком, миллиардером бы был)
|
| 23:17:21 |
Eugene Krokhalev |
|
| 23:17:32 |
Eugene Krokhalev |
Весёлые ребята!
|
| 23:17:41 |
radio-t bot |
⚠️ Вещание подкаста началось - https://stream.radio-t.com/
|
| 23:18:01 |
Ivan Vinogradov |
Типичная АПЛ
|
| 23:18:05 |
Роман Никишин |
Видно вообще ржомба
|
| 23:19:06 |
Роман Никишин |
Вот вы смеетесь, а я когда в финской конторе работал, мы реально ездили в него играть в ленобласть
|
| 23:21:43 |
Alexey Nesterov |
Не, футбол для меня это параллельная вселенная, я ничего не знаю и не смотрю.
|
| 23:23:34 |
Роман Никишин |
Интересно, олды тут помнят про Denwer?)
|
| 23:23:43 |
Grigory Bakunov |
канеш
|
| 23:24:44 |
Anton Kuznetsov |
Фантастическое терпение у умпутуна, конечно. С Греем он так не церемонится в прямом эфире)
|
| 23:25:31 |
Grigory Bakunov |
ты бы сразу зарепортил, да!
|
| 23:26:42 |
Ivan Vinogradov |
Додокерные времена
|
| 23:26:57 |
Ivan Vinogradov |
Было удобно, но PHP
|
| 23:28:02 |
Anton Kuznetsov |
Во, Лёха — мой пездюк) Зарепортить решил)
|
| 23:29:21 |
Alexey Nesterov |
Опытный snowflake
|
| 23:29:41 |
Anton Kuznetsov |
Лёх — легенда)
|
| 23:32:24 |
Egor Miasnikov |
дзен программист
|
| 23:35:05 |
ksenobite |
|
| 23:39:24 |
radio-t bot |
⚠️ How to Collapse Your Stack Using PostgreSQL for Everything - https://www.timescale.com/blog/how-to-collapse-your-stack-using-postgresql-for-everything/?utm_source=reddit
|
| 23:39:31 |
radio-t bot |
How to Collapse Your Stack Using PostgreSQL for Everything
Краткое содержание:
Идея использования PostgreSQL для решения всех задач не нова, но привлекает внимание, поскольку Postgres продолжает набирать популярность. Стремясь к простоте в мире развертывания баз данных, автор предлагает свернуть стек технологий и использовать PostgreSQL для разнообразных задач.
- Проблема разрастания стека технологий: развитие продукта или функционала приводит к использованию множества баз данных, увеличивая сложность и "пунктирную" сложность между системами.
- Зачем сокращать стек: складывая больше задач на одну базу данных, можно упростить ментальное моделирование потока данных, сократить сложность и вернуть время на работу над функциями.
- PostgreSQL для сокращения стека: благодаря обширному функционалу и стабильности, PostgreSQL позволяет обрабатывать различные рабочие нагрузки, предлагает широкие возможности расширений и имеет множество ресурсов для поддержки.
- Выбор "лучшей базы данных для работы": PostgreSQL часто может оказаться оптимальным выбором из-за своей эффективности, простоты в управлении, надежности и интеграции с существующей инфраструктурой.
- Сценарии успеха и неудачи: использование PostgreSQL для всех задач может быть предпочтительнее мультибазовой архитектуры, которая может стать угрозой для стабильности операции в будущем.
- Вывод: Идея "PostgreSQL для всего" направл
|
| 23:40:33 |
yakimka |
Просто Лёха в SQL запросы не умеет, вот и бесится
|
| 23:41:52 |
Mikhail |
какие БД/брокеры последнее время использовали?
|
| 23:42:42 |
yakimka |
Не нужно в заказе делать связь на товары из каталога
|
| 23:43:15 |
Anton Kuznetsov |
а как быть?
|
| 23:43:20 |
Mikhail |
джойны топ, нормальные формы рулят
|
| 23:43:27 |
Алиса |
леха работал в биг тех где миллион сервисов между которыми надо гонять данные ?
|
| 23:44:35 |
Mikhail |
еще jsonb для мусора удобно
|
| 23:45:42 |
Andrey |
А давайте опросник в чат 🤓
|
| 23:46:03 |
Egor Miasnikov |
мне кажется Леха передергивает
|
| 23:46:16 |
yakimka |
Заметно когда кто-то ругает технологию которую никогда не использовал)
|
| 23:47:33 |
Alexey Baranov |
Бойся Кода)
|
| 23:47:47 |
Grigory Bakunov |
wtf?
|
| 23:47:47 |
radio-t bot |
@brunql получает бан на 6дн 20ч 53мин 18сек
|
| 23:48:14 |
Timophey Molchanov |
Не ну а для увеличения флейма, вот у вас большой проект скоуп хреново посчитан, а какая у вас goto database?
Mongodb?
|
| 23:48:16 |
Grigory Bakunov |
напоминаю, у нас тут не место для непрошенных опросов в любой форме. даже если "но я хотел как лучше!"
|
| 23:48:31 |
yelsh |
кхм, стейтменты в аггрегационных пайплайнах монги
|
| 23:49:40 |
yelsh |
в целом мне кажется тут нет смысла винить авторов языка, 50 лет назад был прорыв, все согласны, винить надо разрабов которые это сделали карго культом
первый блин всегда комом, просто никто после этого особо пытался сделать что-то лучше, ведь большую часть кейсов это уже покрывает, какое-бы противное оно не было
|
| 23:49:57 |
Alexey Baranov |
Я уверен, что он не очень искреннен в своей позиции и разжигает ради разжигания)
|
| 23:51:04 |
Sergei Krasnov |
Sql это язык для операций над множествами. Да, он много в чем неудобен, и эволюционирует медленно. Но для своей задачи норм
|
| 23:51:16 |
Alexey Nesterov |
Какой задачи?
|
| 23:51:48 |
Sergei Krasnov |
Работать с множествами
|
| 23:52:00 |
Alexey Nesterov |
Зачем его используют для работы с БД тогда?
|
| 23:52:20 |
Sergei Krasnov |
Потому что обычно туда кладут множества
|
| 23:52:27 |
Alexey Baranov |
Да никакой, так люди играются, нахер все это не надо.
|
| 23:52:45 |
GrayZone |
Кто-то записал Лёхину задачку? Там вроде два джойна ж всего?
|
| 23:52:57 |
yakimka |
там можно и без джойнов
|
| 23:53:06 |
andmеd |
Sql работает
|
| 23:53:10 |
yelsh |
с сабселектами 😬
|
| 23:53:13 |
Sergei Krasnov |
По существу - не джойни если не надо
|
| 23:53:24 |
yakimka |
Го?
|
| 23:53:29 |
Alexey Baranov |
Все в память грузить будем и в форе перебирать
|
| 23:53:34 |
Timophey Molchanov |
Кажется Лёша не хочет лишних данных в выдачи
|
| 23:53:52 |
yelsh |
а какая задачка-то?
|
| 23:54:04 |
Sergei Krasnov |
Надо все ордера клиента - возьми отдельно клиента, потом отдельно его ордера. И не будет тебе в каждой строке повторов
|
| 23:54:49 |
Alexey Nesterov |
Задача - есть заказы, есть строчки в заказе, каждая строчка указывает на товар в каталоге.
|
| 23:54:52 |
Timophey Molchanov |
Получить все заказы
В них все строчки
До них все описания товаров
|
| 23:55:09 |
Alexey Nesterov |
Теоретические это сделать довольно просто и красиво, на практике это невероятно сложно и уродливо.
|
| 23:55:24 |
yakimka |
> указывает на товар в каталоге.
я надеюсь что это чисто для примера)
|
| 23:55:37 |
Alexey Baranov |
Любую базу данных Sql можно использовать как key value, и тд
|
| 23:55:44 |
yakimka |
так а сделать что надо?
|
| 23:55:59 |
Alexey Nesterov |
Соответсвенно нужна модель и пусть теоретическая задача - отчет за день - список всех заказов, в каждом список айтемов, и у каждого айтема цена из каталога.
|
| 23:56:02 |
yelsh |
select distinct name from items where order_id in (select id from orders where customer_id = <ваш кустомер>)
|
| 23:56:06 |
Andrey |
А откуда в этой задачке у вас jsonb появляется?
|
| 23:56:40 |
Alexey Nesterov |
Так а как иначе сгруппировать order items,
|
| 23:56:47 |
yelsh |
не могу судить о читаемости запроса, но кажется что везде, где join нет становится лучше
|
| 23:57:00 |
Anton Kuznetsov |
а почему вам кажется эта задача ненормальной? Это же корзина в любом интернет-магазине
|
| 23:57:26 |
Alexey Nesterov |
Теперь добавь номер заказа из таблицы заказов и цену из каталога
|
| 23:57:39 |
Andrey |
Group by + distinct?
|
| 23:58:03 |
Alexey Nesterov |
Так group by во что? В JSONB?
|
| 23:58:21 |
Sergei Krasnov |
Цена не должна браться из каталога, цена должна быть в Order item
|
| 23:58:33 |
Sergei Krasnov |
Иначе это большой факап
|
| 23:58:38 |
Alexey Baranov |
За jsonb в реляционной базе можно и смузи поить, пока из ушей не польется
|
| 23:58:40 |
Andrey |
Вообще не понимаю причем group by к jsonb
|
| 23:59:02 |
Alexey Nesterov |
Согласен, уже денормализуем (и это правильно). А теперь не только цена, а вообще все про этот айтем - и получается что вся нормализация уже пошла лесом.
|
| 23:59:11 |
Alexey Nesterov |
Ну ты напиши запрос
|
| 23:59:36 |
Andrey |
Я напишу запрос, если будет DDL для наших таблиц обсуждаемых ))
|
| 23:59:42 |
Sergei Krasnov |
Так нормализацию давно никто не задрачивает.
|
| 00:00:01 |
yakimka |
Почему? Это две разных сущности, товар каталога и товар заказанный пользователем
|
| 00:00:13 |
Sergei Krasnov |
Плюс это не про дерномализацию. Это в принципе разная инфа - по чем продали и сколько оно стоит сейчас
|
| 00:00:21 |
Vitalii Pomoinytskyi |
А порекомендуйте бесплатную и отдельно удобную векторную базы
|
| 00:00:25 |
Alexey Nesterov |
Эммм.. ну в этом же и подвох, сделать модель часть задачи 🙂 И она как ни крути получается кривая и косая, и вообще не реляционная.
|
| 00:00:26 |
radio-t bot |
⚠️ Cloudflare took down our website after trying to force us to pay 120k$ within 24h - https://robindev.substack.com/p/cloudflare-took-down-our-website
|
| 00:00:30 |
radio-t bot |
Cloudflare took down our website after trying to force us to pay 120k$ within 24h
Cloudflare выключил наш сайт, пытаясь заставить нас заплатить 120 тыс. долларов за 24 часа.
- Находились на плане "Бизнес" Cloudflare
- Cloudflare потребовал заплатить 120к$ за годовую подписку на "Enterprise"
- Отказались, объяснив необходимость множества доменов
- Cloudflare удалил все домены и DNS-записи без предупреждения
- Начали миграцию на Fastly с перерывами в работе
- Рекомендации при работе с Cloudflare: резервные копии конфигурации, заблокированные домены, не использовать собственные кеширование правила.
|
| 00:00:48 |
Aleksei Gurianov |
Нутром чую что литр, но доказать не могк
|
| 00:01:17 |
yakimka |
Почему?
|
| 00:01:34 |
yelsh |
ну да, согласен, уже менее читаемо и без join никак
select orders.order_id, prices.price, items.name from items
join prices on items.item_id = prices.item_id
join orders on orders.item_id = items.item_id
where orders.customer_id = ?
group by orders.order_id, prices.price, items.name
|
| 00:01:37 |
Alexey Nesterov |
Ну вот так всегда и получается. "Реляционные базы крутые потому что данные нормализованы. Но только в реально мире все равно все денормализуем".
|
| 00:02:10 |
Ivan Vinogradov |
Так они играют в Лондоне, вот почему Алексей должен был бы слышать
|
| 00:02:35 |
Alexey Nesterov |
Group by items.name? Так это выберет уникальные имена, зачем так?
|
| 00:02:51 |
yelsh |
а там где-то читал “без повторов” по-моему
|
| 00:02:54 |
Sergei Krasnov |
Вообще не по этому
|
| 00:03:08 |
Alexey Nesterov |
А, а бы не догадался, что Боруссия играет с Реалом в Лондоне
|
| 00:03:35 |
Ivan Vinogradov |
Финал Лиги Чемпионов. Никогда не угадаешь где будет
|
| 00:03:46 |
Ivan Vinogradov |
Реал победил btw
|
| 00:03:54 |
Alexey Nesterov |
Я так фоном пытаюсь распарсить, но мне не кажется корректным запрос.
|
| 00:04:45 |
Grigory Bakunov |
Гайз! У нас в следствие войны нет света (я точно знаю что тут есть *** которые сейчас ликуют). Простите, но дальше без меня :(
|
| 00:04:46 |
Andrey |
Было бы очень интересно посмотреть хотя бы на вашу нереляционную модель. Но я допускаю, что это просто ходиварная тема, в которую удобно иногда подливать масла в огонь в выпуск-другой 🤓
|
| 00:05:10 |
Alexey Nesterov |
Типа можно забить на group by и выбирать для каждого item еще и данные из order, то есть повторять данные в выборке. Но тогда это читать и собирать в дерево объектов придется на клиенте, либо через ORM, либо самому.
|
| 00:06:16 |
Alexey Nesterov |
Посмотреть на какую модель? У меня ничего такого нет, я представляю примерно как это ненормализованно сделать, и вот и спрашиваю как правильно сделать нормализованно и выборку через SQL.
|
| 00:07:08 |
Andrey |
Можно долго и упорно обсуждать на пальцах. Я же пишу про то, что давайте конкретнее на примерах
|
| 00:07:37 |
Alexey Nesterov |
Так давай, я же неписал что я хочу выше. Или что ты о чем спрашиваешь?
|
| 00:07:59 |
Alexey Nesterov |
Я типа пытаюсь около-рабочие примеры на что-то абстарктное перенести, ну типа интернет магазин.
|
| 00:08:17 |
Andrew Demonov |
сама риторика - "у нас безлимитный траффик, но после 80тб мы вас выгоним на тариф в 10 раз дороже" кажется не очень
|
| 00:08:19 |
Andrey |
Как вы вашу задачу побьете на коллекции в монге с точки зрения данных?
|
| 00:08:19 |
yakimka |
SELECT
o.order_id,
oi.item_id,
oi.item_price
FROM
orders o
JOIN
order_items oi ON o.order_id = oi.order_id;
|
| 00:09:16 |
Alexey Nesterov |
Ну да, так это вернет по строчке на каждый order item? И как потом это мапить на клиенте в объектную структуру?
|
| 00:09:41 |
Alexey Nesterov |
И кажется у тебя ошибка - right join же должен быть?
|
| 00:09:54 |
Alexey Nesterov |
Иначе у тебя будет выбираться рандомный item каждый раз?
|
| 00:09:56 |
radio-t bot |
Выборка данных из двух коллекций по ключу приведет к комбинации всех соответствующих документов. Для преобразования даных в объектную структуру на клиенте можно использовать метод map, чтобы создать объект для каждой пары значений. По поводу типа JOIN, зависит от требуемой логики - inner join или right join.
|
| 00:09:59 |
yakimka |
Мапишь по ордер_айди и пихаешь по своим моделям
|
| 00:10:18 |
Alexey Baranov |
Вы это на полном серьезе спрашиваете?
|
| 00:10:24 |
yakimka |
Почему?
|
| 00:10:25 |
Victor Osipov |
https://docs.oracle.com/javase/tutorial/jdbc/basics/retrieving.html#:~:text=A%20ResultSet%20object%20is%20a,through%20the%20Statement%20object%2C%20stmt%20.
|
| 00:10:36 |
Victor Osipov |
По старому :)
|
| 00:10:39 |
Ilya Starchenko |
Ну как-как. json_agg :)
|
| 00:11:04 |
Alexey Nesterov |
Ну да, а в чем подвох?
|
| 00:11:14 |
Alexey Nesterov |
Ну да, но это же костыль?
|
| 00:11:43 |
Ilya Starchenko |
Ага, при чем огромный, но работает. А если несложный запрос, то даже перфомнее.
|
| 00:12:16 |
Alexey Nesterov |
Ну я и говорю, самому на клиенте мапить. Но это же странно, или только мне так кажется? Сначала вернуть кучу лишних данных, а потом на клиенте с ней разбираться?
|
| 00:12:55 |
yelsh |
https://gist.github.com/Semior001/7f45e81d9207e1206fe53a3508a2a2f9
|
| 00:13:35 |
Sergei Krasnov |
Ну ты правда не понял
|
| 00:13:47 |
Alexey Baranov |
Ясно, понятно.
|
| 00:13:56 |
Ilya Starchenko |
Но евангелисты sql, такие как Лукас Эдер(он sql называет языком 4-ого поколения), примерно так представляют себе современный sql.
|
| 00:14:12 |
yakimka |
Если бы люди так умели, они бы Го не использовали
|
| 00:14:24 |
yelsh |
я не люблю sql, но я не могу сказать что на mongodb например было бы проще
у меня наоборот сложнее получается, в аггрегационных пайплайнах фигова туча стейтментов, которые тоже понять трудновато
|
| 00:15:02 |
Alexey Nesterov |
Так без шуток, в чем мой вопрос такой странный был?
|
| 00:15:12 |
Ivan Vinogradov |
Некоторые sql базы умеют курсор возвращать в поле, там не будет дубликатов строк
|
| 00:15:25 |
Ivan Vinogradov |
Тред не читал)
|
| 00:15:31 |
Vyacheslav Kuznetsov |
C SQL как с демократией - да, плох, но ничего лучше до сих пор не придумано
|
| 00:16:21 |
radio-t bot |
⚠️ Don't DRY Your Code Prematurely - https://testing.googleblog.com/2024/05/dont-dry-your-code-prematurely.html
|
| 00:16:25 |
radio-t bot |
Google Testing Blog: Don't DRY Your Code Prematurely
Краткое содержание: Статья в блоге Google Testing об опасностях преждевременной минимизации повторений в коде.
- Напоминание о вреде преждевременной минимизации повторений в коде
- Уточнение о важности сохранения читаемости кода
- Предложение фокусироваться на читаемости и стабильности кода
- Совет о применении DRY-принципа взвешенно и в нужные моменты
- Осознание значимости дублирования для упрощения отладки
- Вызов не спешить с оптимизацией перед фактическим необходимым порядком
- Подчеркивается значимость удобочитаемости и понятности кода.
|
| 00:16:41 |
Alexey Nesterov |
Так а что он в этом примере вернет тогда?
|
| 00:16:54 |
yelsh |
|
| 00:17:17 |
Alexey Nesterov |
Скорее как коммунизм - когда он проваливается, то все говорят "Не, ну это была не настоящая реляционная модель и SQL"
|
| 00:17:46 |
Alexey Nesterov |
Так ID 0 два раза в результате. И по другому никак.
|
| 00:18:21 |
Sergei Krasnov |
Смысл реляционок в acid а не в джойнах
|
| 00:18:23 |
Alexey Nesterov |
Либо group by в JSON, либо повторять данные и потом на клиенте это все разгребать (Hibernate сам умел, кажется). И это и проблема - это ж костыли.
|
| 00:18:30 |
yelsh |
необходимо их сгруппировать под один order?
|
| 00:18:58 |
Alexey Nesterov |
Ну наверное, потом же их надо как-то в доменную модель мапить.
|
| 00:19:32 |
Sergei Krasnov |
Так через орм без кастомных запросов
|
| 00:19:38 |
Alexey Baranov |
Во первых по заказу можно сгруппировать довольно простым кодом на streams в java, (или еще чем) при желании это можно сделать и на sql. Сильно непонятно почему это сильно сложно или непонятно.
|
| 00:19:53 |
yelsh |
я просто такого не видел, ну тут только компоновать в json и возвращать, тогда да, получится уродливо
с другой стороны на стороне приложения после того как ответ с pgsql спарсился в массив, я бы просто мапой сгруппировал бы
|
| 00:20:15 |
GrayZone |
Я так понял, проблема с SQL, что не хватает агрегатных функций для такой группировки в стандарте?
Кажется, в clichouse достаточно разных добавили, там это должно проще делаться, чтобы с json'ом не заморачиватьс
|
| 00:20:20 |
Alexey Nesterov |
Плюс выше уже сказали - то надо денормализовать, цена может уже поменялась, явно надо копировать в item. Но тогда по идее надо вообще всю инофрмацию копировать, ну вдруг мы описание товара на момент покупки хотим?
|
| 00:21:08 |
Sergei Krasnov |
Надо, а в монге у вас не так?
|
| 00:21:25 |
Alexey Nesterov |
Я понимаю, это не очень сложно и понятно. Но это же костыль. Неужели тебя тут ничего прям не коробит? Ты такой смотришь на 100 копий order id в ответе и такой "Норм".
|
| 00:21:34 |
Ivan Vinogradov |
Там можно иерархичный объект получить сразу
|
| 00:21:44 |
Alexey Nesterov |
Монга умеет в дерево объектов собрать, там же все объект.
|
| 00:21:46 |
Alexey Baranov |
Те даже дедовским фором пройтись и в мап запихать, а странным показалось — будто это секрет и создается впечатление тролигга
|
| 00:21:56 |
Ilya Starchenko |
Даже хибер не всегда это нормально делает. Например, только в 6-ой версии пофиксили, что fetch join не возвращает дублей, а это основная задача фреймворка библиотеки. А если пользоваться чем-то нормальным типа jdbcTemplate(или pure jdbc) или вообще sqlx в го, то становится больно.
|
| 00:22:20 |
Alexey Nesterov |
Не хватает и они в реляционную модель и декларативный язык с ооочень большим трудом влазят.
|
| 00:22:41 |
Ilya Starchenko |
Мы сделали модель данных, которую нужно подпереть костылями, чтобы ею можно было пользоваться нормально. Найс.
|
| 00:22:54 |
Alexey Nesterov |
Ну вон выше объяснили уже что это просто и очевидно как сделать 😉
|
| 00:22:54 |
yelsh |
в случае если у тебя объекты в разных коллекциях, то сборка результата становится адом
|
| 00:23:11 |
Alexey Nesterov |
Это да, Монга тоже не без греха.
|
| 00:23:38 |
Alexey Nesterov |
А в итоге я хочу аналогичную задачу решить тупо без джойнов вообще, просто выполняя пачку запросов.
|
| 00:23:59 |
Alexey Nesterov |
Ну типа сначала вытащить orders, потом foreach в коде, на каждый сделать запрос items и т.п.
|
| 00:24:19 |
Alexey Baranov |
Да, норм, потому что у всех технологий есть свои недостатки и этот вот пример — ну ерунда, а не недостаток
|
| 00:24:26 |
yakimka |
🤔
|
| 00:24:37 |
Alexey Nesterov |
Так я же не говорю, что нельзя сделать. Просто это выглядит как костыль.
|
| 00:24:58 |
Alexey Nesterov |
Уродство, но что делать, мы сами такой мир создали.
|
| 00:25:15 |
Alexey Baranov |
Хм, я то же предлагал для sql результата, примерно
|
| 00:25:19 |
yakimka |
так а причем тут уродство, это же N+1
|
| 00:25:43 |
Ivan Vinogradov |
В sql получение иерархичных структур лучше делать в N запросов просто. Сначала собираем верхнеуровневые orders. Потом вторым запросом уже items через id in (:ids). Иначе это оверхед жестокий, особенно, если там не 10-100 строк, а тысячи и более
|
| 00:25:55 |
Alexey Nesterov |
Так в целом так и живем, я же не спорю. Но это же не значит что надо просто утереться и терпеть, хочется же сделать мир лучше и чтобы была красота.
|
| 00:25:56 |
Ivan Vinogradov |
И это уродство, да
|
| 00:26:08 |
yakimka |
в принципе как и в nosql
|
| 00:26:28 |
Ivan Vinogradov |
Ну я думал, что там принято сразу одним делать дерево
|
| 00:26:32 |
yakimka |
https://www.edgedb.com/
|
| 00:27:18 |
yelsh |
в случае если у тебя иерархичный объект который еще и может ссылаться сам на себя, то без существенных просадок в оптимизации ты кусками собрать его не сможешь
пример - таблица с директориями, директория может быть в директории, тут без join или без рекурсии никак
|
| 00:27:19 |
Ivan Vinogradov |
Надо 2 параллельных подкаста вести)
|
| 00:27:54 |
Ivan Vinogradov |
Ну я бы предпочел такую модель данных не делать
|
| 00:28:02 |
Andrey |
Отдельный для sql обсуждений завести?)
|
| 00:28:54 |
Ivan Vinogradov |
Просто отдельный стрим с Алексем, который слушает других ведущих и параллельно с чатом общается, иногда отвечает в основном подкасте
|
| 00:29:20 |
Alexey Nesterov |
Я бы такое не стал слушать 🙂
|
| 00:29:25 |
Ivan Vinogradov |
N стримов под каждого ведущего в метаспейсе
|
| 00:31:15 |
Alexey Nesterov |
Вот вроде графовые базы данных еще как-то подходят под реальный мир, но я с ними не работал in anger. Пока моя надежда это Datomic, но опять же, может я романтизирую так как не работал в продакшене с ним.
|
| 00:31:19 |
yakimka |
А асерты в го вообще есть?
|
| 00:32:30 |
yakimka |
Ксюша дело говорит
|
| 00:33:07 |
Ivan Vinogradov |
Всё просто. В го нет исключений, но есть, но как бы нет, но есть, … segfault
|
| 00:34:45 |
yelsh |
про текущую тему разговора - звучит как паника в библиотеке 😬
в stdlib таких много
|
| 00:34:53 |
Ivan Vinogradov |
Есть, кстати, статьи как в go реализовать исключения))
|
| 00:35:29 |
yakimka |
Yes, Go has a built-in assert package, but it is intended for internal testing purposes within the Go standard library and is not recommended for use in user code.
🤔
|
| 00:35:41 |
Alexey Nesterov |
Вот если уж говорть про идеальный мир, я бы хотел написать
select order.id, items as (select qty, name as (select price from catalog where catalog.id = item.catalog_id as of item.tx = catalog.tx) from items where order_id = order.id as of order.order_datetime)
То есть все данные должны быть темпоральными, а запрос и драйвер должен уметь строить иерархии объектов и выбирать данные по времени или tx (состоянию базы).
|
| 00:35:55 |
Alexey Nesterov |
Самое близкое это реально xtdb или datomic.
|
| 00:36:07 |
Ilya Starchenko |
Мне кажется, что реляционные базы такие популярные скорее не потому что людям нужна реляционность, а потому что они хорошо умеют делать констрейнты для соблюдения целостности данных.
|
| 00:36:51 |
Ilya Starchenko |
Другой вопрос, что часто можно обойтись и без них, но это нужно заботиться о дизайне, а тут тебя и база может прикрыть в случае чего 🙂
|
| 00:37:25 |
Alexey Nesterov |
Ну это же дикий оверкилл, это просто вопрос валидации данных.
|
| 00:37:28 |
Ivan Vinogradov |
Такое можно сделать в Oracle и вроде в Postgres. В поле будет курсор, который также можно построчно вычитать
|
| 00:37:55 |
Ivan Vinogradov |
Не уверен также, что это оптимально для БД будет
|
| 00:38:31 |
yakimka |
Не, не убедил
|
| 00:38:52 |
Ivan Vinogradov |
Гавно, зато понятное и рука набита)
|
| 00:39:12 |
yakimka |
DRY отвратительная фигня, особенно при написании тестов
|
| 00:39:58 |
Alexey Nesterov |
Так и живем, да
|
| 00:40:06 |
radio-t bot |
⚠️ Why, after 6 years, I’m over GraphQL - https://bessey.dev/blog/2024/05/24/why-im-over-graphql/
|
| 00:40:12 |
radio-t bot |
Why, after 6 years, I’m over GraphQL
После 6 лет я перестал использовать GraphQL из-за осложнений связанных с безопасностью, производительностью и сложностью в поддержке.
- Увеличение поверхности атак: необходимость борьбы с различными видами атак
- Авторизация: необходимость правильной авторизации каждого поля на основе контекста
- Ограничение скорости: необходимость оценки сложности запросов для предотвращения перегрузок
- Анализ запросов: проблемы, связанные с обработкой невалидных запросов
- Производительность: проблемы с избыточной загрузкой данных и N+1 проблема
- Связывание бизнес-логики с транспортным уровнем
- Сложность: увеличение сложности кодовой базы, неудобства в отладке
**Альтернативы:**
- Рекомендация OpenAPI 3.0+ с JSON REST API для контроля всех клиентов и использования нескольких языков
- Использование FastAPI в Python и tsoa в TypeScript для генерации OpenAPI спецификаций
- Возможность спецификации первым делом, что соответствует подходу schema first в GraphQL, но с генерацией кода из рукописной спецификации.
|
| 00:41:21 |
GrayZone |
Сегодня день, когда в radio-t хотят все базы данных обложить?
|
| 00:42:35 |
Alexey Baranov |
Я вполне понимаю поинт, но он на вполне понятной идее основывается, что таблички на объекты так себе матчатся (по этому все ORM — отстой и костыль в некотором смысле), но возбуждение общества (в лице меня в том числе) основывается на желании выкинуть с водой ребенка и отменить SQL совсем вот)
|
| 00:43:32 |
yakimka |
А че, с OpenAPI не так чтоли?
|
| 00:45:14 |
Alexey Nesterov |
Сложные времена требуют жестких мер. Будем писать все на YAML-е вместо SQL.
|
| 00:45:47 |
Aleksei Gurianov |
GraphQl как раз можно зафиксировать
|
| 00:46:15 |
Aleksei Gurianov |
В девелопе позволять все, в проде только фикс
|
| 00:48:26 |
yakimka |
Ну и дичь
|
| 00:49:05 |
yakimka |
Забавно как Лёха почти в одной и той же манере ругает SQL и защищает графкуэл)
|
| 00:49:55 |
Andrey |
Потому что второе - это всего лишь сложно и нетривиально, но сделать возможно )
|
| 00:53:21 |
Andrew Demonov |
ну и чем это отличается от клаудфлера? 😂
|
| 00:55:38 |
Alexey Nesterov |
А что в этом забавного, это же не пересекающиеся технологии? И я же выше говорил, я говорю свои впечатления после активной работы с технологией. С GraphQL есть свои заморочки, но рвотного рефлекса в отличе от SQL при решении даже тривиальных задач не было. Возможно, конечно, пока не было.
|
| 00:58:31 |
Alexey Baranov |
GrapQL позволяет фронту запрашивать много чего, в целом непредсказуемого. Это как минимум может привести к проблемам с производительностью
|
| 00:59:22 |
Alexey Baranov |
Слишком многое надо предусматривать, ага, как и в ресте чистом
|
| 00:59:30 |
yelsh |
Ну как непересекающиеся, по доке БД умеют в него. Вот тут у меня небольшой вопрос - для БД querying это было бы нервотным?
|
| 01:00:02 |
Dmitry Dorofeev |
Но можно же комплексити запроса ограничивать осознанно
|
| 01:00:06 |
Alexey Baranov |
Много так сказать ключей для кеширования
|
| 01:00:47 |
Alexey Baranov |
А чем тогда это отличается от явных ендпоинтов?
|
| 01:02:03 |
Dmitry Dorofeev |
Тем что можно запросить что угодно, но чуть чуть
|
| 01:02:34 |
Alexey Baranov |
Чет сложно, тонкий момент
|
| 01:05:20 |
Alexey Baranov |
А где тонко — там и рвется
|
| 01:08:08 |
Alexey Baranov |
Алексей тут говорит что граф куель — это такой способ презентации API
|
| 01:10:46 |
Alexey Baranov |
Ну заменить query string
|
| 01:12:53 |
Alexey Baranov |
Ксения, но бекенд вытащит все)
|
| 01:15:00 |
Alexey Baranov |
И отрубить на фронтенде из общей картинки
|
| 01:16:27 |
Alexey Baranov |
Удалять нельзя
|
| 01:19:39 |
radio-t bot |
⚠️ Темы слушателей 912 - https://radio-t.com/p/2024/05/28/prep-912/
|
| 01:19:55 |
radio-t bot |
[1/16] +16 от rubonz
A purported leak of 2,500 pages of internal documentation from Google sheds light on how Search operates.
https://www.theverge.com/2024/5/28/24166177/g...
https://ipullrank.com/google-algo-leak
Google won’t comment on a potentially massive leak of its search algorithm documentation - The Verge
Google не комментирует потенциально массовое утечку документации по своему поисковому алгоритму - The Verge
- Алгоритм поиска Google - одна из наиболее важных систем в интернете, регулирующая жизнь сайтов и содержание в сети
- Утечка документов предоставляет уникальный взгляд на работу поиска Google
- Документы обсуждают сбор и использование данных, ранжирование сайтов по чувствительным темам, обращение со смалнйыми сайтами и другие темы
- Некоторая информация в документах противоречит публичным заявлениям представителей Google
- Слово "ложь" используется для характеристики недостоверной информации, предоставленной Google
- Разоблачение документов может изменить отношение к информации, предоставляемой Google
- Документы демонстрируют глубокий взгляд на закрытую систему алгоритмов Google
- Внутренняя документация Google становится доступной через процесс антимонопольного дела против компании в США.
|
| 01:19:55 |
radio-t bot |
[2/16] +9 от Alex Martsinovich
Jetbrains Space закрывается. Причина: «реалии не соответствовали нашему видению продукта».
Link: https://blog.jetbrains.com/space/2024/05/27/t...
The Future of Space | The Space Blog
**Будущее космоса: обновления в продукте Space**
- Создание Space с целью предоставить решение для ИТ-компаний
- Интеграция Space с инструментами сторонних разработчиков
- Конец проекта Space, запуск нового продукта SpaceCode
- Влияние на клиентов Space и предлагаемые им опции
- Поддержка клиентов в период перехода
- Планы на перспективу продукта и обещание оказывать поддержку пользователям
**Options for Space customers:**
- Отказ от подписки на Space и предоставление тех. поддержки до мая 2025 г.
- Организации с годовой подпиской могут перейти на SpaceCode Preview и получить TeamCity и YouTrack подписки
- Организации с ежемесячной подпиской могут также перейти на SpaceCode Preview и получить TeamCity и YouTrack подписки
- Space Free клиенты могут бесплатно использовать SpaceCode Preview и получить TeamCity и YouTrack подписки
- Расширение срока действия текущей подписки Space для компенсации за перенос данных
- Обеспечение подробной информацией и инструкциями по миграции данных
- Поддержка и помощь клиентам в период перехода к новому продукту.
|
| 01:19:56 |
radio-t bot |
[3/16] +9 от Vlad Khononov
AWS согласились с Умпутуном: S3 больше не будет брать деньги за ответы со статусом 403.
А Бобук, если не ошибаюсь, обещал написать сайт, который будет раздавать контент только таким статусом
https://aws.amazon.com/about-aws/whats-new/20...
Amazon S3 will no longer charge for several HTTP error codes
Изменения в оплате Amazon S3 для нескольких HTTP-кодов ошибок:
- Новые правила оплаты распространяются на все регионы AWS, включая AWS GovCloud (US) и AWS China.
- Изменения начали действовать сегодня.
- Неавторизованные запросы, не инициированные клиентом, теперь бесплатны.
- Владельцы бакетов не будут платить за запросы, возвращающие ошибку HTTP 403 (Access Denied) от внешних аккаунтов AWS.
- Полный список ошибочных кодов, для которых не взимается оплата, доступен в документации.
- Изменения в оплате не требуют изменений в приложениях клиентов.
- Новые правила оплаты применяются ко всем S3 бакетам.
|
| 01:19:56 |
radio-t bot |
[4/16] +8 от Alexander Karpov
Блокировка Docker hub для ru ip
|
| 01:19:56 |
radio-t bot |
[5/16] +5 от Ilya Patrikeev
Google Cloud опубликовали инцидент репорт по следам удаления аккаунта UniSuper
https://cloud.google.com/blog/products/infras...
Details of Google Cloud GCVE incident | Google Cloud Blog
Подробности инцидента с Google Cloud GCVE
- При развертывании GCVE Private Cloud для клиента произошла недопустимая конфигурация из-за незаполненного параметра, что привело к автоматическому удалению облака через 1 год.
- Инцидент не затронул другие услуги Google Cloud, только облако GCVE данного клиента.
- Google приняли меры, чтобы исключить повторение подобных ситуаций, включая депрекацию внутреннего инструмента и исправление системного поведения.
- Компания Microsoft и ее клиентская команда работали 24/7 для быстрого восстановления и восстановления полноценной работы облака.
- Резервное копирование данных в Google Cloud Storage и использование стороннего программного обеспечения для копирования оказались ключевыми при восстановлении.
- Google приняли меры для обеспечения безопасности, включая депрекацию инструмента и проверку всех GCVE Private Clouds для выявления рисков.
- Google указали на отсутствие системных проблем и подтвердили наличие современных механизмов безопасности.
- Гигант облачных услуг подчеркнул важность сотрудничества с клиентами для быстрого восстановления после инцидента и подчеркнул важность надежного управления рисками.
|
| 01:30:26 |
Aleksei Gurianov |
Бобук обещал построить сайты на 403 ошибках
|
| 01:31:46 |
Alexey Baranov |
Вообще не надо выдумывать бакет — его должны выдавать
|
| 01:32:46 |
Alexey Baranov |
А то анекдот про пароль у пользователя Пети уже есть
|
| 01:32:57 |
yakimka |
Где они были 8 лет
|
| 01:43:44 |
Роман Никишин |
А Драйв и не вспомнили(
|
| 01:45:23 |
Алексей |
Грей смотрел фильм, да еще и на русском ?
|
| 01:46:25 |
Alexey Baranov |
Накамура давно обыграл комплюхтер, но это да, давно было
|
| 01:47:28 |
Роман Никишин |
Луа по скорости на одной полочке с Си и Джулией
|
| 01:50:00 |
Andrew Demonov |
Выключение поддержки vbs в винде равносильно выключению поддержки sh-скриптов в линуксе
|
| 01:50:45 |
Роман Никишин |
|
| 01:50:59 |
Alexey Baranov |
Трамп по не федеральному обвинению осужден
|
| 01:51:24 |
Alexey Baranov |
Поэтому и не может себя помиловать
|
| 01:52:41 |
Alexey Baranov |
Да выйграит)
|
| 01:53:14 |
Alexey Baranov |
Даже из турьмы
|
| 01:53:33 |
Alexey Baranov |
Это возможно
|
| 01:53:43 |
Алексей |
Один маразматик, второго в тюрьму хотят посадить🤣 кто страной рулить ?
|
| 01:53:44 |
radio-t bot |
Не думаю, что это мудрое решение. Важно выбирать достойных лидеров для страны.
|
| 01:58:02 |
Sergiy Petrenko |
|
| 01:58:32 |
Sergiy Petrenko |
нет, я смотрел фильм на английском, но включили субтитры.
|