15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Backend as a Service: что такое BaaS и когда его использовать
Аутентификация, база данных, хранение файлов и обновления в реальном времени — типовые задачи можно закрыть готовой платформой. Именно такой подход предлагают BaaS-сервисы.
В статье freeCodeCamp разобрали основные возможности BaaS, сценарии применения и платформы вроде Firebase, Supabase и Appwrite. В конце — короткий пример начала работы с Firebase. Материал вводный, подойдёт для знакомства с темой.
Читать статью
👉 @BackendPortal
Во многих приложениях есть такой эндпоинт.
Фронтенд удаляет JWT после того, как пользователь нажимает «Выйти». Но вот вопрос… Действительно ли пользователь вышел из системы?
Что, если:
• JWT скопировали до выхода?
• Срок действия токена ещё не истёк?
• Другое устройство всё ещё использует тот же токен?
• Будет ли ваш бэкенд по-прежнему принимать этот JWT?
Как вы реализуете выход из системы в архитектуре со stateless JWT?
👉 @BackendPortal
Каждое приложение просит ввести пароль. Но мало кто из инженеров знает, что происходит после нажатия кнопки «Зарегистрироваться».
В продакшене пароль никогда не должен храниться в открытом виде или расшифровываться.
Обычно процесс выглядит так:
• Браузер отправляет пароль по HTTPS.
• Бэкенд сразу хеширует его с помощью Argon2, bcrypt или PBKDF2.
• Добавляется уникальная соль.
• Сохраняется только хеш и, как правило, соль.
• При входе пароль снова хешируется, а результат сравнивается с сохранённым.
Современные системы идут дальше: ограничивают частоту запросов, используют MFA, дополнительный секрет (pepper), обнаружение утечек и безопасное управление сессиями.
Если база данных будет скомпрометирована, злоумышленники не должны найти в ней пароли в открытом виде.
👉 @BackendPortal
Тренажёр SQL для бэкенд-разработчиков
Полезный ресурс, чтобы освоить SQL или освежить базу перед собеседованием. Формат простой: короткое объяснение, затем практические задания с запросами прямо в браузере.
https://sqlbolt.com/
👉 @BackendPortal
Правильный ответ: Главная проблема не в try/catch, а в том, что err.message возвращается напрямую клиенту.
В продакшене это может раскрыть внутренние детали: ошибки SQL, названия таблиц, пути к файлам, трассировки стека или даже версии библиотек. Такая информация помогает злоумышленникам проводить дальнейшие атаки.
Записывайте подробную информацию об ошибке в серверные логи, а клиенту возвращайте общее сообщение, например:500 Internal Server Error «Что-то пошло не так. Пожалуйста, попробуйте позже».
Также используйте корректные HTTP-коды статуса (404, 400, 403, 500), вместо того чтобы всегда возвращать 200 с объектом ошибки.
👉 @BackendPortal
99% путаницы между Inbound и Outbound исчезает, если перестать думать об инструментах и начать думать о направлении трафика.
Вот самое простое объяснение: Inbound Traffic. Всё, что входит в вашу систему.
Примеры:
• Browser → Your Server
• Mobile App → Backend API
• Another Microservice → Your Service
Ваша система принимает request. Outbound Traffic. Всё, что выходит из вашей системы.
Примеры:
• Backend → Payment Gateway
• Backend → Banking API
• Backend → Database
• Backend → Cache
• Backend → Email Service
• Server → другой внутренний или внешний Backend
Ваша система сама инициирует соединение. Представьте приложение доставки еды:
1. Вы открываете приложение и запрашиваете список ближайших ресторанов.
→ Для backend это Inbound Traffic.
2. Backend обращается к Maps service, Payment service или Recommendation engine.
→ Это уже Outbound Traffic — server-to-server requests.
Причём один и тот же request может быть:
• Outbound для Service A
• Inbound для Service B
Сама сеть не меняется. Меняется только точка зрения.
В следующий раз при debugging проблемы в production задайте один вопрос:
Этот request входит в мою систему или моя система сама обращается к другой системе? Этот простой принцип помогает гораздо быстрее разбираться в logs, firewalls, proxies, APIs, microservices и cloud networking, чем простое заучивание определений.
👉 @BackendPortal
Вы создали composite index:
(first_name, last_name, city)
SELECT *
FROM users
WHERE last_name = 'Smith';
last_name входит в него?WHERE first_name = ?
WHERE first_name = ? AND last_name = ?
WHERE first_name = ? AND city = ?
Объектное хранилище в эпоху быстрых данных
Объём данных, с которыми нужно работать, растёт ежедневно. Стандартных решений уже не хватает для задач ИИ и аналитики. Большие объёмы данных нужно не только хранить, но и быстро записывать и читать.
В MWS Cloud Platform мы построили объектное хранилище не только на привычных HDD-дисках, но и на NVMe. На вебинаре покажем, какие сценарии работы это открывает и как меняет привычные подходы.
Подключайтесь! Обсудим:
✅ Чем классы хранения MWS Object Storage отличаются от привычных
✅ В каких сценариях новый тёплый класс проявляет себя лучше всего
✅ Преимущества и слабые места в разных сценариях работы
📆 7 октября в 14:00 (мск)
Зарегистрироваться
DevOps-инструмент недели: sofka
Kubernetes говорит, что что-то сломалось. Но говорит ли он, почему именно? Приходится проверять статус, события, логи и пытаться понять, в чём проблема.
Именно это решает sofka.
sofka — это TUI для Kubernetes, вдохновлённый k9s. Он показывает состояние rollout, деградировавшие состояния, блокирующие поды и последние warning-события
Вот что он умеет:
• Объясняет, почему ресурс сломан, а не просто сообщает, что с ним проблема
• Встроенная поддержка Flux CD: можно приостанавливать, возобновлять и запускать reconcile без установленного Flux CLI
• Инспектор Helm: история релизов, values и сгенерированные манифесты без установленного Helm
• Есть фильтры вроде cpu>500m, restarts>=5, age<2h, чтобы быстро находить именно то, что нужно
• Можно просматривать таймлайн всех изменений объекта, которые зафиксировал инструмент
• Можно просматривать и передавать файлы напрямую из PVC
• Можно выбрать несколько подов и смотреть их логи одновременно
• Поддержка плагинов Popeye и Trivy
Согласно бенчмаркам проекта, sofka открывает представление подов на 59% быстрее k9s и использует меньше половины его объёма памяти.
В следующий раз, когда деплой зависнет и придётся по кусочкам выяснять, что произошло, попробуйте sofka.
Начать здесь: http://github.com/nklmilojevic/sofka
👉 @BackendPortal
Roadmap, которому стоит следовать, чтобы стать сильным Backend Developer в 2026 году:
1. Programming Fundamentals
• Java
• OOP
• Collections
• Multithreading
• Exception Handling
2. Backend Core
• APIs
• Authentication
• JWT/OAuth
• Validation
• File Uploads
3. Databases
• SQL
• Indexing
• Transactions
• Query Optimization
• Redis Caching
4. Scalability
• Load Balancing
• Async Processing
• Queues
• Rate Limiting
• Distributed Systems
5. DevOps & Deployment
• Docker
• CI/CD
• Kubernetes
• Monitoring
• Logging
6. Production Engineering
• Observability
• Performance Tuning
• Security
• Incident Debugging
• Cost Optimization
Большинство разработчиков ограничиваются изучением frameworks. Сильные backend-разработчики понимают, как работают системы, масштабирование и приложения в production.
👉 @BackendPortal
Backend Checklist — День 15: CORS
Ваш API работает в Postman. Работает через curl. Но стоит вызвать его из браузера — и внезапно появляется CORS error.
> Дело в браузере, а не в сервере
Request может успешно дойти до сервера. Сервер может даже вернуть 200. Но браузер всё равно может запретить frontend читать response, если CORS headers настроены неправильно.
Postman и curl не волнует CORS. Браузер — волнует.
> Preflight, который вы не отправляли
Здесь всё становится интереснее. Вы отправляете POST с JSON, добавляете Authorization header или используете PUT / DELETE. Перед фактическим request браузер может сначала отправить OPTIONS request. Если сервер не обработает его правильно, основной request вообще не будет отправлен. Именно поэтому GET может работать, а POST — внезапно нет.
> Wildcard, который не работает с credentials
Если вы отправляете credentials, то:
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Backend Checklist — День 14: Schema Validation
Ваш endpoint получает age из request body и прибавляет к нему 1. Месяцами всё работает нормально. А затем client отправляет age как "twenty", и необработанный TypeError приводит к ошибке где-то глубоко внутри приложения — далеко от handler, который изначально получил request.
Валидируйте данные на входе, а не внутри business logic.
Request body — это недоверенные входные данные. Schema явно определяет, что именно принимает приложение: названия полей, типы данных, ограничения и обязательные значения.
Валидные данные попадают в приложение как проверенный, строго типизированный object. Невалидные сразу отклоняются на HTTP boundary с 422 Unprocessable Content или 400 Bad Request.
Без schema каждой downstream function приходится самостоятельно перепроверять входные данные. И первая функция, которая забудет это сделать, может стать причиной следующего production incident.
Есть два важных поведения, о которых стоит знать при работе с Pydantic или serializers вашего framework.
Первое — coercion. По умолчанию "123" может превратиться в 123: строка незаметно преобразуется в объявленный тип. Это удобно, но может скрыть ошибку client, который отправляет данные неправильного типа. Strict mode отключает такое поведение.
Второе — extra fields. Необъявленное поле может быть молча отброшено без ошибки. Например, если отправить is_admin в schema, где такого поля нет, оно просто исчезнет. Но если raw input затем попадёт напрямую в model, принятие лишних полей может стать уязвимостью. Настройка extra='forbid' позволяет отклонять такие данные.
Парсите и валидируйте данные один раз на входе, чтобы core logic работала только с теми структурами данных, для которых она была создана.
👉 @BackendPortal
Главное правило SQL GROUP BY, которое должен знать каждый
Если в SELECT используются неагрегированные столбцы, убедитесь, что они добавлены в GROUP BY. Это не просто хорошая практика — в некоторых базах данных это обязательное требование.
Почему это важно?GROUP BY определяет, что представляет собой одна строка результата. База данных должна точно понимать, какое единственное значение поместить в каждую ячейку этой строки.
В запросе ниже одна строка = одна должность (job_title) внутри конкретного отдела (department). Поэтому и department, и job_title должны присутствовать в GROUP BY.
Если пропустить неагрегированный столбец:
• Некоторые СУБД вернут ошибку
• Другие могут вернуть произвольное значение
• Запрос может «работать» сегодня, но завтра вернуть некорректный результат
Общее правило
Каждый столбец в SELECT должен быть функционально зависим от GROUP BY. Если внутри одной группы столбец может содержать несколько значений, его нужно либо добавить в GROUP BY, либо использовать с агрегатной функцией.
👉 @BackendPortal
Backend Checklist — День 13: JSON Serialization
Serialization — это преобразование Python objects в текст для передачи по сети. Звучит как простая смена формата, но на деле это скорее перевод, а при переводе часть информации может потеряться.
В JSON всего семь типов, а у ваших objects их гораздо больше
Весь набор типов JSON — это object, array, string, number, true, false, null. И всё. Никаких datetime, Decimal, set, UUID или bytes. Поэтому более сложные типы приходится преобразовывать, иначе json.dumps() завершится с TypeError:
• datetime, UUID, Decimal — соответствующего JSON-типа нет, поэтому их обычно преобразуют в строки
• set, bytes — прямого аналога тоже нет, поэтому нужно выбрать представление: например, set → list, а bytes → Base64
• tuple — незаметно превращается в array, а после десериализации возвращается уже как list
Последний пример отлично показывает суть проблемы. Вы сериализуете tuple, а десериализуете уже list. Данные сохранились, но тип — нет.
Object, который вы получаете обратно, — не обязательно тот же object, который вы отправили
Round trip через JSON может быть lossy. datetime превращается в строку и останется строкой, пока кто-то явно не преобразует её обратно. Decimal, если привести его к float, чтобы он поместился в JSON, вернётся как float и потенциально потеряет точность.
Serialization — это перевод на язык, в котором всего семь «слов». Всё, для чего в JSON есть собственный тип, сохраняется напрямую. Для всего остального нужны соглашения, понятные обеим сторонам, иначе информация не переживёт передачу.
Например, в Python:
json.loads(json.dumps(("a", "b")))["a", "b"]
Сегодня последний день регистрации на КосмоХакатон
18–20 сентября, Петербург, Красноярск или онлайн из любой точки страны. Четыре задачи на выбор: снабжение орбитального топливного узла и безопасность космонавта в открытом космосе в Петербурге (фонд 1,2 млн ₽), мониторинг лесных пожаров и верификация углеродных кредитов по спутниковым снимкам в Красноярске (600 тыс. ₽). Есть и для тех, кто про данные и ML, и для тех, кто про стратегию и экономику.
Лучшие забирают приз на площадке и билет в московский финал 25–27 сентября, где разыграют ещё 2,4 млн рублей.
Команду можно собрать на платформе.
Подробности и регистрация
База данных может обрабатывать миллионы строк...
Но всего один плохой SQL-запрос способен серьёзно просадить её производительность.
Большинство проблем с SQL performance связаны с:
• SELECT *
• Отсутствующими indexes
• Неоптимальными JOIN
• Full Table Scan
• Игнорированием EXPLAIN
Вот SQL Optimization Cheat Sheet, который поможет писать более быстрые и эффективные запросы. Сохраните — пригодится во время следующего performance tuning.
👉 @BackendPortal
HTTP/1.1 ≠ HTTP/2 ≠ HTTP/3 Все они передают веб-страницы… Но каждое поколение устраняло существенное ограничение производительности.
Вот простой способ запомнить различия:
HTTP/1.1
➜ Один запрос за раз на соединение. Просто, но медленно для современных сайтов.
HTTP/2
➜ Несколько запросов могут использовать одно TCP-соединение благодаря мультиплексированию.
HTTP/3
➜ Работает поверх QUIC на базе UDP, снижая задержки и устраняя блокировку начала очереди на транспортном уровне.
Как быстро запомнить
HTTP/1.1 = последовательная обработка.
HTTP/2 = мультиплексирование.
HTTP/3 = мультиплексирование + более быстрое восстановление.
Какие изменения принесла каждая версия?
HTTP/1.1
• Для загрузки множества ресурсов нужны несколько TCP-соединений.
• Текстовый протокол.
• Блокировка начала очереди (head-of-line blocking) на уровне приложения.
HTTP/2
• Мультиплексирование в рамках одного TCP-соединения.
• Бинарный протокол.
• Сжатие заголовков с помощью HPACK.
• Меньше соединений, выше производительность.
HTTP/3
• QUIC вместо TCP.
• Более быстрое установление соединения.
• Лучшая производительность в нестабильных и мобильных сетях.
• Повышенная устойчивость к потере пакетов.
Частый вопрос на собеседовании: Если HTTP/2 уже поддерживает мультиплексирование, зачем понадобился HTTP/3?
Потому что HTTP/2 по-прежнему использует TCP. При потере пакета TCP может задерживать другие потоки в том же соединении. HTTP/3 использует QUIC поверх UDP, позволяя потокам восстанавливаться более независимо и снижая задержки в ненадёжных сетях.
Одна формулировка, чтобы запомнить навсегда:
• HTTP/1.1 = по одному
• HTTP/2 = несколько одновременно
• HTTP/3 = несколько одновременно, даже в плохой сети
Сохранил эту рукописную шпаргалку для всех, кто изучает сети, бэкенд-разработку или готовится к собеседованиям по проектированию систем.
👉 @BackendPortal
Два бэкенд-инженера предложили разные архитектуры загрузки файлов.
Вариант A: Загружать каждый файл через бэкенд.
Вариант B: Загружать файлы напрямую в S3 по предподписанным URL (pre-signed URLs).
Приложение должно обрабатывать миллионы загрузок.
Какой вариант выберете для продакшена и почему?
👉 @BackendPortal
Оффер в IT за 3 дня - да!
Вот такой крутой кейс получился у команды ИИ-ассистента Софи🤘
Пользователь зашел на триал, не заплатил за подписку и успел получить оффер с отклика, который сделал бот.
▫️Направление - бэкенд разработка
▫️3 приглашения на собес за 72 часа
▫️Оффер, с зарплатой на 20.000 больше указанной в резюме
Зайти на 3 бесплатных дня в Софи можно уже сейчас.
Регистрируйся здесь.
Вопрос с собеседования по бэкенду
В этом коде есть серьёзная уязвимость. На первый взгляд всё выглядит нормально. Но в продакшене вы фактически даёте злоумышленникам карту вашей системы.
Сможете найти проблему?
👉 @BackendPortal
Как AI становится чем-то большим, чем дефолтным ускорителем отдельных операцией
Уже сейчас появляются агенты, которые сами принимают решения и могут взаимодействовать в реальном физическом мире. На прошедшей deep tech night Станислав Макеев рассказывал, как такие технологии работают в Лавке. И на примере доставки хорошо видно, насколько большой это сдвиг.
Когда лавка только запускалась, директор даркстора вручную распределял заказы между курьерами. Потом это стали делать уже алгоритмы: они оптимизировали время доставки, количество заказов и загрузку курьеров. Затем подключились и ML-модели, которые научились точнее предсказывать отдельные параметры.
Сейчас мы на этапе, когда агент способен сам оценивать ситуацию целиком и решать, что делать дальше.
И тут вылезает подводный камень: развивать интеллект самой модели — не самое главное. Когда в Лавке начали запускать агентов, оказалось, что часть админок вообще не имеет API, данные приходят с задержкой, а инструкции для людей могут противоречить друг другу. Пришлось перестраивать саму инфраструктуру: добавлять интеграции, защищать критичные действия и выносить жесткие правила из промптов в код.
Причем агенту не дают сразу полную свободу. Сначала он работает в shadow mode — наблюдает за реальным процессом и предлагает решение, а человек проверяет его. Потом автономность постепенно расширяется: агенту разрешают самостоятельно действовать только там, где его решения уже достаточно хорошо проверены.
Сейчас такие агенты работают примерно в 30 дарксторах. До конца года его хотят раскатать на всю сеть и отдельно проверить сценарий, где агент уже сам управляет процессом. Он может следить за метриками, находить отклонения и разбирать типовые ситуации, а человеку остаются переговоры и другие сложные задачи.
Если бы пришлось заново изучать System Design в 2026 году, я бы придерживался такого roadmap:
1. Foundation
Networking
HTTP/HTTPS
DNS
Reverse Proxy
TLS/SSL
2. Data Layer
SQL vs NoSQL
Indexing
Replication
Sharding
CAP Theorem
3. Scaling Basics
Caching
CDN
Load Balancing
Rate Limiting
Backpressure
4. Async & Messaging
Kafka/RabbitMQ
Pub/Sub
Event-Driven Systems
WebSockets
Background Jobs
5. Distributed Systems
Consistency Models
Consensus
Fault Tolerance
Leader Election
Idempotency
6. Real-World Design
YouTube
Uber
WhatsApp
Payment Systems
X
Многие разработчики сразу переходят к задачам вроде «Спроектируйте WhatsApp». Но именно хорошее понимание фундаментальных вещей значительно упрощает изучение продвинутого System Design.
Цель — не запоминать архитектурные схемы. Цель — понимать trade-offs. Сохраняйте этот roadmap, если изучаете System Design.
👉 @BackendPortal
Ваш API работает медленно.
Что проверите первым?
• Добавите database index
• Увеличите ресурсы сервера
• Добавите больше replicas
• Обвините сеть
Вместо этого сначала проследите весь путь request:
Client
→ DNS
→ Load Balancer
→ API Server
→ Database
→ External Services
А затем измерьте время на каждом этапе. Backend с ответом за 10 мс не поможет, если браузер загружает bundle размером 15 МБ.
Исправный API не поможет, если database query выполняется 4 секунды. И быстрая database не спасёт, если сторонний API постоянно уходит в timeout.
«API работает медленно» — это не диагноз. Это отправная точка для диагностики.
Я собрал практический API Debugging Cheat Sheet с основными проверками, командами, HTTP status codes, распространёнными проблемами и быстрыми способами их устранения.
👉 @BackendPortal
Полезная шпаргалка по SQL: основы JOIN-запросы и агрегация
Изучите базовые операции SQL: выборку данных, объединение таблиц с помощью JOIN, агрегирование с функциями COUNT, AVG, SUM и создание подзапросов. Эта шпаргалка станет вашим надежным помощником в ежедневной работе с SQL.
Полная PDF версия тут ⬇️
👉 @BackendPortal
⚡️⚡️Joker 2026: что происходит с профессией разработчика
Индустрия разработки проходит через серьезный переломный момент. Меняются не только инструменты и фреймворки, но и привычный подход к работе.
Поэтому в этом сезоне меняется и Joker: первый день традиционно посвящен Java — Core Java, рантайму и работе на уровне железа. А во второй день будем обсуждать, как прямо сейчас меняется сама инженерная практика.
В программе — Context Engineering, команды из людей и ИИ-агентов, Self-Evolving Agents, новые подходы к архитектуре и работе с моделями, а также вопросы ответственности и роли эксперта.
Собрали главные темы второго дня в карточках.
🌟С промокодом: BackendPortal персональные билеты дешевле
Полное расписание и билеты — на сайте.
Большой бесплатный гайд по SQL для начинающих
На freeCodeCamp лежит полноценный текстовый курс по SQL, который ведёт от самых основ до более серьёзных тем. Материал построен последовательно и подойдёт тем, кто только начинает разбираться в реляционных базах данных.
Внутри: таблицы и типы данных, CRUD, SELECT и WHERE, constraints, агрегатные функции, подзапросы, нормализация, JOIN и основы оптимизации запросов. Для практики в курсе используется SQLite, при этом отдельно разбираются различия между SQL-базами.
Хороший материал, чтобы системно пройти SQL с нуля или освежить базу.
👉 @BackendPortal
Не нарушайте принцип единственной ответственности
Функция должна делать одну вещь, делать её хорошо и только её.
Эта функция делает слишком много:
def calculate_final_total(
price: float,
quantity: int,
discount_rate: float,
tax_rate: float
) -> float:
# Расчёт промежуточной суммы
subtotal = price * quantity
# Применение скидки
discounted_amount = subtotal * (1 - discount_rate)
# Расчёт налога
final_total = discounted_amount * (1 + tax_rate)
return final_total
def calculate_subtotal(price: float, quantity: int) -> float:
return price * quantity
def apply_discount(subtotal: float, discount: float) -> float:
return subtotal * (1 - discount)
def calculate_tax(amount: float, tax_rate: float) -> float:
return amount * (1 + tax_rate)
👩💻 Всем программистам посвящается!
Вот 14 авторских обучающих IT каналов по самым востребованным областям программирования:
Выбирай своё направление:
👩💻 Python — t.me/python_ready
🤔 InfoSec & Хакинг — t.me/hacking_ready
🖥 SQL & Базы Данных — t.me/sql_ready
👩💻 IT Новости — t.me/it_ready
🤖 AI & ML — t.me/neuro_ready
👩💻 Frontend — t.me/frontend_ready
👩💻 C/C++ — /channel/cpp_ready
👩💻 C# & Unity — t.me/csharp_ready
👩💻 Linux — t.me/linux_ready
👩💻 Java — t.me/java_ready
📖 IT Книги — t.me/books_ready
📱 JavaScript — t.me/javascript_ready
🖼️ DevOps — t.me/devops_ready
🖥 Design — t.me/design_ready
📌 Гайды, шпаргалки, задачи, ресурсы и фишки для каждого языка программирования!
Удивительно, как часто путают программу, процесс и поток.
Вот простое объяснение.
1. Программа
Это файл на диске, содержащий набор инструкций.
Одна программа может запускать несколько процессов.
Например, Firefox может создавать отдельные процессы для разных компонентов.
2. Процесс
Это программа, которая уже выполняется.
Программа превращается в процесс, когда загружается в память и запускается.
Для работы процесс использует, например, счётчик команд, стек и регистры.
3. Поток
Поток — минимальная единица выполнения внутри процесса.
Один процесс может содержать много потоков.
Например, браузер одновременно выполняет несколько потоков. Один может загружать содержимое, другие — отрисовывать анимации, воспроизводить видео и выполнять другие задачи.
Главные различия между процессами и потоками:
• процессы независимы, а потоки существуют внутри процесса
• у каждого процесса своё адресное пространство памяти, а потоки одного процесса делят общую память
• переключение между процессами обычно дороже
• обмен данными между потоками быстрее, чем между процессами
• создание и завершение потока обычно легче и быстрее
👉 @BackendPortal
БОЛЬШОЙ SQL-ГРЕХ
Использовать операторы NOT IN или IN, когда в данных присутствует NULL.
В SQL оператор IN — это сокращённая запись нескольких условий OR, а сравнение value = NULL всегда возвращает UNKNOWN. Из-за этого запрос может вернуть неожиданный результат или вообще пустую выборку.
Если нужно учитывать NULL, обрабатывайте его явно. Добавьте условие IS NULL к IN или используйте другой подход, корректно учитывающий NULL.
Всегда тестируйте SQL-запросы с NULL, чтобы убедиться, что они работают так, как ожидается.
👉 @BackendPortal