Вопрос на SQL собеседовании.

Какой оператор имеет больший приоритет AND или OR (если они используются совместно)?

Ответ:

AND имеет больший приоритет, нежели OR

#sql #собеседование

Google Research представила Gemini-SQL2 - новую систему text-to-SQL на базе Gemini 3.1 Pro.

Она превращает вопросы на обычном языке в исполняемые SQL-запросы, позволяя получать данные из баз без ручного написания кода.

На бенчмарке BIRD система показала state-of-the-art результат - 80,04% execution accuracy.

BIRD реально запускает запрос и проверяет, возвращает ли он правильный результат.

https://x.com/GoogleResearch/status/2065475343205740911

@data_analysis_ml

Сегодня вместо опроса настоящий хакатон: Ozon Tech запустил Робозон с задачами по автоматизации складов и призовым фондом 15 000 000 рублей.

Три трека:
— имитационное моделирование сортировочного центра;
— инженерные решения для автоматизированной сортировки;
— системы компьютерного зрения для классификации товаров.

Всё на реальных данных, и решать можно онлайн. Команду можно собрать свою или вписаться в существующую на платформе хакатона. И до 6 сентября есть время предложить решение.

Тех, кто пройдёт в финал, организаторы привезут на E-CODE. На конференции пройдёт и защита, и награждение. Проезд и проживание за счёт компании.

Регистрация до 11 июля.
Задачи уже выложены на сайте

Одна маленькая звёздочка в SQL может незаметно просадить весь backend.

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

Но потом в таблицу добавляют тяжёлый JSON, аватар, длинный текст или служебные данные. И старый код внезапно начинает таскать лишние мегабайты на каждый запрос.

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

Поэтому в продакшене лучше выбирать только те поля, которые реально нужны приложению.

Звёздочка удобна для быстрой проверки. Но в рабочем коде это та самая лень, которая потом больно бьёт по продакшену.

#sql #backend #database #postgresql #mysql #разработка #программирование #devtips #webdev

Классика

Тест прошёл. А PostgreSQL вообще в курсе?

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

На локалке всё зелёное. В CI всё зелёное. Моки довольны. In-memory база тоже не против. А потом в проде внезапно выясняется, что реальный PostgreSQL иначе обрабатывает запрос, constraint не даёт сохранить данные, транзакция ведёт себя не так, как ожидалось, а Redis показывает проблему, которую тесты вообще не могли поймать.

Именно поэтому Testcontainers в .NET так хорошо заходят для интеграционных тестов. Вместо имитации базы вы поднимаете настоящий PostgreSQL, Redis или другой сервис в Docker-контейнере, прогоняете приложение против реальной зависимости и удаляете контейнер после тестов.

Это даёт намного больше уверенности, чем тесты против подмены. При этом не нужен общий тестовый сервер, который кто-то сломал, не почистил или настроил иначе.

В хорошей схеме контейнеры запускаются через fixture, приложение получает connection string динамически, версии образов фиксируются, а настройка прячется за небольшими helper-классами. Сам тест при этом остаётся читаемым: он проверяет бизнес-сценарий, а не превращается в простыню из настройки базы и очистки состояния.

Есть важный нюанс. Общие fixtures ускоряют тесты, но требуют дисциплины со shared state. Когда изоляция важнее скорости, лучше использовать отдельные fixtures и не ловить фантомные падения из-за данных, оставшихся от соседнего теста.

Мне нравится этот подход именно за баланс. Вы тестируете не идеальную игрушечную модель приложения, а поведение, максимально близкое к реальному окружению. Но без боли ручной инфраструктуры.

Поэтому в следующий раз, когда интеграционный тест прошёл против in-memory базы, стоит задать неприятный вопрос: а настоящая база с ним согласится?

Вы можете выучить SQL по «Тетради смерти»

О времена, о нравы)

SQL-инъекция за 40 секунд: Лайт против L

Разбираем SQL-инъекцию на пальцах в формате Лайт против L. Что это такое, как обычная строка ввода меняет логику запроса, к чему это приводит и какими способами реально закрыть дыру. Коротко, по делу и так, чтобы запомнилось.

Больше таких видео: https://www.youtube.com/shorts/c4gBi094jkU

@sqlhub

`O_DIRECT`: когда база данных обходит page cache

В Linux флаг O_DIRECT позволяет читать и писать файл почти напрямую, минуя page cache ядра.

Зачем это нужно базам данных?

У PostgreSQL, MySQL, RocksDB и других систем часто уже есть свой buffer pool.
Если ещё и ядро будет кэшировать те же страницы, получится двойное кэширование и лишняя трата памяти.

Но у O_DIRECT есть неприятное условие: всё должно быть выровнено по блоку.

• buffer
• file offset
• размер чтения / записи

Например, под 4 KB блоки нельзя просто так прочитать 123 байта в любой `malloc`-буфер.
Промахнулся с alignment — read() вернёт EINVAL.

Именно поэтому низкоуровневый I/O в базах выглядит таким странным: там важны не только данные, но и то, как они лежат в памяти.