Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design. в мессенджере MAX — 2 314 подписчиков, аналитика и статистика

Последние публикации канала «Базы Данных (Data Base) | SQL & NoSQL. PostgreSQL, MySQL и Big Data. Уроки для Backend и Data Engineer. Архитектура БД, Оптимизация и Design.»

1. 269 просмотров, 14 июн. 2026 г.

   🔗 Сравнение: Типы JOIN в SQL и когда их применять Зачем понимать JOIN’ы? Правильный выбор типа соединения таблиц позволяет получать необходимые данные эффективно и избегать неожиданных «пустых» или дублирующихся строк. 1. Основные типы JOIN и их поведение INNER JOIN Возвращает только строки, у которых есть совпадения в обеих таблицах. Когда нужно только пересечение данных. LEFT JOIN Берёт все строки из левой таблицы и совпадающие из правой (NULL, если нет). Когда важно сохранить все данные «слева» даже без пары. RIGHT JOIN Аналог LEFT, но берёт все из правой таблицы. Редко…

2. 359 просмотров, 13 июн. 2026 г., изображение

   Получи грант до 1,35 млн руб. на обучение в магистратуре Хочешь развиваться в сфере ИТ и получить фундаментальные знания с практикой? Поступай в магистратуру Центрального университета! — 4 офлайн программы по востребованным направлениям ИТ — 2 онлайн-программы: машинное обучение и продуктовый менеджмент — 550 грантов до 75% — Вечерние занятия и учеба по выходным — удобно совмещать с работой — Обучение по модели STEM-образования: на стыке науки, технологий и бизнеса — Возможность стажировок и трудоустройства в ведущих компаниях — Государственный диплом за 2 года Магистратура в Центральном…

   
3. 559 просмотров, 11 июн. 2026 г.

   Индексы в PostgreSQL: когда и как ставить, чтобы ускорить запросы 🔍 Что такое индекс? Индекс в PostgreSQL - это структура данных (обычно B-tree), позволяющая быстро находить строки по значению столбца, не сканируя всю таблицу. ⚙️ Пример создания простого B-tree-индекса -- Ускоряем поиск по полю email CREATE INDEX idx_users_email ON users (email); ✅ Best Practices 1. Выбирай правильный тип 🔹 BTREE - по умолчанию, для большинства операций сравнения (=, <, >, BETWEEN). 🔹GIN/GiST - для полнотекстового поиска (tsvector), работы с массивами и геоданных. 🔹HASH - для строго равенств (=),…

4. 587 просмотров, 10 июн. 2026 г., изображение

   Локальный запуск LLM перестал быть экспериментом Всё больше команд разворачивают модели внутри своей инфраструктуры, чтобы контролировать данные, снижать зависимость от внешних сервисов и гибко управлять вычислительными ресурсами. 🔻 23 июня в 20:00 МСК приглашаем вас на открытый урок в преддверии старта курса «ИИ для разработчиков». На занятии мы разберём: ✔️ как устроена платформа Ollama для локального запуска LLM ✔️ рассмотрим установку на Linux, macOS и Windows, ✔️ работу с модельным каталогом, управление версиями и методы оптимизации моделей под ограниченные ресурсы ✔️ также…

   
5. 581 просмотров, 10 июн. 2026 г., изображение

   ❌ Антипаттерн: булевы значения как строки В таблице users встречал такое: is_active VARCHAR(5) -- значения 'true' или 'false' На первый взгляд — ерунда. На практике: – нет валидации: можно вставить 'tru', 'yes', '0', – медленнее сравнение, чем у BOOLEAN, – больше места в хранилище, – сложно агрегировать и строить аналитику. 🔧 Как надо: is_active BOOLEAN DEFAULT true – Экономия места (1 байт против 5 и больше) – Проверка через WHERE is_active – Простой COUNT(*) FILTER (WHERE is_active) для отчётов – Автоматическая поддержка в ORM и UI-форматах 📌 Даже если тебе нужно больше состояний -…

   
6. 649 просмотров, 09 июн. 2026 г., изображение

   🔧 Mini-гайд: ускоряем JOIN-ы в больших таблицах JOIN-ы - мощный инструмент SQL, но на больших объёмах данных могут стать узким горлышком. Вот 5 проверенных способов ускорить их: 1. Индексы по ключам соединения Без индекса - каждый JOIN превращается в полный перебор. ➤ Пример: CREATE INDEX idx_user_id ON orders(user_id); 2. Ограничь объём данных до JOIN-а Фильтруй и агрегируй данные до объединения. ➤ Вместо: SELECT * FROM orders o JOIN users u ON o.user_id = u.id WHERE u.country = 'DE'; ➤ Лучше: WITH german_users AS ( SELECT id FROM…

   
7. 759 просмотров, 08 июн. 2026 г., видео

   Хотите перейти в Компьютерное зрение (CV) или прокачаться до экспертного уровня? Проверьте свои силы, пройдя вступительное тестирование по CV, сравните уровень с рынком и получите скидку 15% на обучение: [контакт скрыт] Вы сможете оценить свои знания в глубоком обучении, нейросетях для изображений и современных архитектурах компьютерного зрения. Преимущества программы курса: 🚀 110 часов практики на реальных задачах 🚀 Современный стек: PyTorch, YOLO, CLIP, SAM, Stable Diffusion 🚀 Рабта с видео, 3D-сценами и мультимодальными моделями 🚀 Подготовка моделей к production через ONNX, TensorRT…

8. 394 просмотров, 2 реакций, 08 июн. 2026 г., видео

   Хотите перейти в Компьютерное зрение (CV) или прокачаться до экспертного уровня? Проверьте свои силы, пройдя вступительное тестирование по CV, сравните уровень с рынком и получите скидку 15% на обучение: [контакт скрыт] Вы сможете оценить свои знания в глубоком обучении, нейросетях для изображений и современных архитектурах компьютерного зрения. Преимущества программы курса: 🚀 110 часов практики на реальных задачах 🚀 Современный стек: PyTorch, YOLO, CLIP, SAM, Stable Diffusion 🚀 Рабта с видео, 3D-сценами и мультимодальными моделями 🚀 Подготовка моделей к production через ONNX, TensorRT…

9. 793 просмотров, 08 июн. 2026 г., изображение

   Антипаттерн: SELECT * - удобно, но опасно Использовать SELECT * - значит звать всех на вечеринку, даже если звал только двоих. Почему это плохо: 🔹 Излишняя нагрузка на сеть и СУБД - выбираются все столбцы, включая ненужные. 🔹 Проблемы с индексами - СУБД может не использовать покрывающий индекс. 🔹 Ломается при изменении схемы - добавил столбец → внезапно изменилось поведение приложения. 🔹 Сложнее читать и поддерживать - особенно в JOIN’ах. ✅ Как правильно: Запрашивай только нужные поля: SELECT id, name, created_at FROM users; 📌 И даже в админках/аналитике лучше явно указывать поля -…

   
10. 456 просмотров, 4 реакций, 08 июн. 2026 г., изображение

    Антипаттерн: SELECT * - удобно, но опасно Использовать SELECT * - значит звать всех на вечеринку, даже если звал только двоих. Почему это плохо: 🔹 Излишняя нагрузка на сеть и СУБД - выбираются все столбцы, включая ненужные. 🔹 Проблемы с индексами - СУБД может не использовать покрывающий индекс. 🔹 Ломается при изменении схемы - добавил столбец → внезапно изменилось поведение приложения. 🔹 Сложнее читать и поддерживать - особенно в JOIN’ах. ✅ Как правильно: Запрашивай только нужные поля: SELECT id, name, created_at FROM users; 📌 И даже в админках/аналитике лучше явно указывать поля -…

    
11. 438 просмотров, 4 реакций, 07 июн. 2026 г.

    🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. https://max.ru/tipsysdmin Типичный Сисадмин Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование…

12. 982 просмотров, 06 июн. 2026 г., изображение

    🛑 Антипаттерн: "Списки через запятую" в базе данных Признайтесь, у каждого был соблазн сделать это. У вас есть сущность (например, User), и нужно сохранить список их ролей или IDs купленных товаров. Создавать отдельную таблицу кажется оверхедом, и вы решаете: "А, запишу просто строкой через запятую". В БД это выглядит так: role_ids: "1,4,12" Почему это бомба замедленного действия и как это лечить? Давайте разбираться. Почему это плохо: 1. Сложный поиск. Найти всех пользователей с role_id = 1 через LIKE '%1%' - это больно. Вы найдете и 1, и 12, и 100. Придется писать монструозные…

    
13. 677 просмотров, 10 реакций, 06 июн. 2026 г., изображение

    🛑 Антипаттерн: "Списки через запятую" в базе данных Признайтесь, у каждого был соблазн сделать это. У вас есть сущность (например, User), и нужно сохранить список их ролей или IDs купленных товаров. Создавать отдельную таблицу кажется оверхедом, и вы решаете: "А, запишу просто строкой через запятую". В БД это выглядит так: role_ids: "1,4,12" Почему это бомба замедленного действия и как это лечить? Давайте разбираться. Почему это плохо: 1. Сложный поиск. Найти всех пользователей с role_id = 1 через LIKE '%1%' - это больно. Вы найдете и 1, и 12, и 100. Придется писать монструозные…

    
14. 1.1K просмотров, 04 июн. 2026 г., изображение

    PostgreSQL или MySQL? Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇 🔷 PostgreSQL: 🔵 Поддержка JSONB с индексами - почти как NoSQL внутри SQL 🔵 CTE, оконные функции, полнотекстовый поиск - топ для аналитики 🔵 Расширяемость: можно писать свои типы, функции, операторы 🔵 Хорош для сложных запросов, аналитики, геоданных (PostGIS) 🔻 Минусы: – Сложнее в настройке и оптимизации – Меньше хостингов out-of-the-box (но всё быстро меняется) 🔶 MySQL (особенно InnoDB / MariaDB): 🔵 Быстрее на простых…

    
15. 795 просмотров, 11 реакций, 04 июн. 2026 г., изображение

    PostgreSQL или MySQL? Один из самых частых вопросов от разработчиков и DevOps - “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇 🔷 PostgreSQL: 🔵 Поддержка JSONB с индексами - почти как NoSQL внутри SQL 🔵 CTE, оконные функции, полнотекстовый поиск - топ для аналитики 🔵 Расширяемость: можно писать свои типы, функции, операторы 🔵 Хорош для сложных запросов, аналитики, геоданных (PostGIS) 🔻 Минусы: – Сложнее в настройке и оптимизации – Меньше хостингов out-of-the-box (но всё быстро меняется) 🔶 MySQL (особенно InnoDB / MariaDB): 🔵 Быстрее на простых…