es
Feedback
Базы данных (Data Base)

Базы данных (Data Base)

Ir al canal en Telegram

Базы данных (Data Base). По всем вопросам @evgenycarter

Mostrar más
8 085
Suscriptores
-224 horas
-67 días
-2330 días
Atraer Suscriptores
agosto '26
agosto '26
+49
en 0 canales
julio '26
+61
en 0 canales
Get PRO
junio '26
+49
en 0 canales
Get PRO
mayo '26
+81
en 0 canales
Get PRO
abril '26
+56
en 0 canales
Get PRO
marzo '26
+85
en 0 canales
Get PRO
febrero '26
+92
en 0 canales
Get PRO
enero '26
+82
en 0 canales
Get PRO
diciembre '25
+87
en 0 canales
Get PRO
noviembre '25
+137
en 31 canales
Get PRO
octubre '25
+101
en 1 canales
Get PRO
septiembre '25
+178
en 36 canales
Get PRO
agosto '25
+159
en 1 canales
Get PRO
julio '25
+197
en 27 canales
Get PRO
junio '25
+215
en 19 canales
Get PRO
mayo '25
+201
en 44 canales
Get PRO
abril '25
+227
en 40 canales
Get PRO
marzo '25
+202
en 38 canales
Get PRO
febrero '25
+176
en 31 canales
Get PRO
enero '25
+230
en 33 canales
Get PRO
diciembre '24
+183
en 34 canales
Get PRO
noviembre '24
+188
en 32 canales
Get PRO
octubre '24
+192
en 29 canales
Get PRO
septiembre '24
+250
en 28 canales
Get PRO
agosto '24
+137
en 17 canales
Get PRO
julio '24
+139
en 0 canales
Get PRO
junio '24
+176
en 23 canales
Get PRO
mayo '24
+169
en 19 canales
Get PRO
abril '24
+161
en 0 canales
Get PRO
marzo '24
+202
en 20 canales
Get PRO
febrero '24
+178
en 18 canales
Get PRO
enero '24
+289
en 23 canales
Get PRO
diciembre '23
+246
en 25 canales
Get PRO
noviembre '23
+246
en 17 canales
Get PRO
octubre '23
+266
en 18 canales
Get PRO
septiembre '23
+247
en 0 canales
Get PRO
agosto '23
+192
en 0 canales
Get PRO
julio '23
+185
en 0 canales
Get PRO
junio '23
+223
en 0 canales
Get PRO
mayo '23
+217
en 0 canales
Get PRO
abril '23
+309
en 0 canales
Get PRO
marzo '23
+282
en 0 canales
Get PRO
febrero '23
+168
en 0 canales
Get PRO
enero '23
+175
en 0 canales
Get PRO
diciembre '22
+224
en 0 canales
Get PRO
noviembre '22
+174
en 0 canales
Get PRO
octubre '22
+321
en 0 canales
Get PRO
septiembre '22
+380
en 0 canales
Get PRO
agosto '22
+295
en 0 canales
Get PRO
julio '22
+538
en 0 canales
Get PRO
junio '22
+569
en 0 canales
Get PRO
mayo '22
+891
en 0 canales
Get PRO
abril '22
+3 160
en 0 canales
Fecha
Crecimiento de Suscriptores
Menciones
Canales
26 agosto+2
25 agosto+2
24 agosto+1
23 agosto+5
22 agosto+4
21 agosto+3
20 agosto+1
19 agosto+2
18 agosto+2
17 agosto+1
16 agosto+1
15 agosto+1
14 agosto+6
13 agosto+3
12 agosto+1
11 agosto+3
10 agosto+1
09 agosto0
08 agosto0
07 agosto+1
06 agosto+3
05 agosto+1
04 agosto+1
03 agosto+2
02 agosto+1
01 agosto+1
Publicaciones del Canal
🔥 Оптимизация SQL-запросов: 5 ключевых техник Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не люби
🔥 Оптимизация SQL-запросов: 5 ключевых техник Сегодня я покажу вам, как ускорить выполнение SQL-запросов, ведь никто не любит ждать, пока база данных "думает". 🚀 1️⃣ Используйте индексы Индексы – это ускоритель запросов. Если у вас часто выполняются WHERE, JOIN или ORDER BY по определенному столбцу – создайте для него индекс. Но не переборщите: индексы ускоряют чтение, но замедляют вставку и обновление данных. 2️⃣ Избегайте SELECT * Выбирайте только нужные столбцы. SELECT * может загружать ненужные данные и нагружать сервер. Лучше указывать конкретные столбцы. 3️⃣ Нормализация или денормализация? Иногда стоит разбивать таблицы (нормализация) для устранения дублирования данных. В других случаях – наоборот, объединять (денормализация) ради быстродействия. Анализируйте ситуацию! 4️⃣ Кеширование запросов Если запрос выполняется часто и данные редко меняются, используйте QUERY CACHE или внешние кеширующие механизмы (Redis, Memcached). 5️⃣ Анализируйте планы выполнения Команда EXPLAIN в MySQL/PostgreSQL покажет, как СУБД выполняет запрос. Это поможет найти узкие места: медленные JOIN'ы, сканы всей таблицы и т.д. 💡 Используете ли вы эти техники? Напишите, какой метод вам помог ускорить работу БД! 📲 Мы в MAX #db 👉 @database_info

2
🚀 Подборка полезных 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 Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса) Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии в IT📌 https://max.ru/progjob https://max.ru/channel_rabotait Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Городские📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП https://max.ru/channel_krasnodar_novosty Краснодар Новости https://max.ru/channel_novosibirsk_novosti Новосибирск https://max.ru/channel_samara_novosti Новости Самары https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга https://max.ru/channel_kazan_novosti Новости Казани https://max.ru/channel_omsk_novosti Новости Омска https://max.ru/channel_moskva_24 Москва 24
362
3
Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀 Сейчас я покажу вам, почему простое добавление индексов не всегд
Оптимизация запросов: Индексы vs. Анализ плана выполнения 🚀 Сейчас я покажу вам, почему простое добавление индексов не всегда ускоряет запросы. Часто встречаю ситуацию, когда разработчики по умолчанию добавляют индексы на каждое поле WHERE, но запросы всё равно работают медленно. Давайте разберёмся! 🔹 Миф: индексы всегда ускоряют запросы На самом деле, индекс может даже замедлить выполнение, если: ✅ Запрос возвращает слишком много строк - сканирование индекса будет дороже, чем полное сканирование таблицы. ✅ Индекс не покрывает весь запрос - приходится делать обращения к основной таблице. ✅ Слишком много индексов - это замедляет INSERT/UPDATE/DELETE. 🔹 Как правильно анализировать? Используйте EXPLAIN ANALYZE (PostgreSQL) или EXPLAIN FORMAT=JSON (MySQL) для понимания: 🔍 Используется ли индекс? 🔍 Сколько строк проходит сканирование? 🔍 Есть ли операции сортировки, которые можно избежать с индексом? 🔹 Что делать, если запрос медленный? 1️⃣ Проверить план выполнения (не добавлять индекс вслепую!). 2️⃣ Подумать о составных индексах, если запрос фильтрует по нескольким полям. 3️⃣ Проверить, можно ли избежать сортировки (ORDER BY по индексу). 4️⃣ Рассмотреть материализованные представления для сложных агрегатов. 📲 Мы в MAX #db 👉 @database_info
605
4
🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения? 🛠 Основные проблемы: 🔹 Чрезмерное количество JOIN – мо
🔥 Оптимизация сложных SQL-запросов: Как уменьшить время выполнения? 🛠 Основные проблемы: 🔹 Чрезмерное количество JOIN – могут приводить к тяжелым вычислениям. 🔹 Неправильные индексы – или их отсутствие вообще. 🔹 Подзапросы вместо JOIN – иногда работают хуже, чем соединения. 🔹 Ненужные SELECT * – выбираем только нужные колонки. 🔹 Фильтрация после JOIN – фильтруем данные как можно раньше. ✅ Как ускорить запрос? 1️⃣ Проверьте индексы – используйте EXPLAIN перед выполнением запроса. Если сканируется весь таблица (Full Table Scan), значит, нужны индексы. 2️⃣ Разбейте сложный запрос на части – иногда лучше записать результат во временную таблицу. 3️⃣ Избегайте SELECT * – указывайте только нужные колонки. 4️⃣ Используйте EXISTS вместо IN – в подзапросах это часто работает быстрее. 5️⃣ Тестируйте с разными JOIN – попробуйте INNER JOIN, LEFT JOIN, а в некоторых случаях UNION. 6️⃣ Оптимизируйте сортировку – ORDER BY без индексов тормозит запрос. 📲 Мы в MAX #db 👉 @database_info
621
5
Шпаргалка по оконным функциям в SQL 📲 Мы в MAX #db 👉 @database_info+1
Шпаргалка по оконным функциям в SQL 📲 Мы в MAX #db 👉 @database_info
663
6
🚀 Оптимизация запросов в SQL: как не утонуть в данных Сегодня хочу поделиться мыслями на тему, которая часто становится болью для многих разработчиков баз данных — оптимизация SQL-запросов. Когда база данных растёт, а запросы становятся сложнее, даже небольшой промах может привести к тому, что ваш сервер начнёт "плакать" под нагрузкой. Вот несколько советов, которые помогут вам держать запросы в тонусе: 1. Индексы — ваш лучший друг (и враг, если использовать неправильно) Индексы ускоряют поиск данных, но их избыток может замедлить вставку и обновление. Используйте их с умом: - Индексируйте только те столбцы, которые часто используются в условиях WHERE, JOIN и ORDER BY. - Избегайте индексов на столбцах с низкой селективностью (например, пол с значениями "М" и "Ж"). 2. Анализируйте план выполнения запроса Перед тем как оптимизировать, нужно понять, что именно тормозит. Используйте EXPLAIN (или EXPLAIN ANALYZE в PostgreSQL) для анализа плана выполнения. Обратите внимание на: - Полноценные сканирования таблиц (Seq Scan). - Вложенные циклы (Nested Loop), которые могут быть медленными на больших данных. - Использование временных таблиц и сортировок. 3. Избегайте N+1 проблемы Если вы работаете с ORM, убедитесь, что не делаете лишних запросов. Например, вместо того чтобы выбирать связанные данные в цикле, используйте JOIN или prefetch_related (в Django). 4. Кэшируйте то, что можно кэшировать Не все данные нужно каждый раз запрашивать из базы. Используйте кэширование для часто запрашиваемых данных. Redis или Memcached — отличные инструменты для этого. 5. Нормализация — это хорошо, но не всегда Нормализация базы данных помогает избежать дублирования данных, но иногда денормализация может значительно ускорить запросы. Например, если у вас есть сложные агрегации, подумайте о создании материализованных представлений. 6. Следите за статистикой Базы данных часто используют статистику для оптимизации запросов. Убедитесь, что она актуальна. Например, в PostgreSQL можно обновить статистику с помощью команды ANALYZE. 7. Не забывайте про мониторинг Используйте инструменты для мониторинга производительности базы данных, такие как pg_stat_activity в PostgreSQL или Performance Schema в MySQL. Это поможет вовремя выявить "узкие" места. 📲 Мы в MAX #db 👉 @database_info
696
7
Безумные и забавные факты о SQLite ⚫️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент актив
Безумные и забавные факты о SQLite ⚫️SQLite — самая часто разворачиваемая и используемая база данных. На текущий момент активно используется более одного триллиона (1000000000000 или миллиона миллионов) баз данных SQLite. ⚫️Её поддерживают три человека. Они не допускают внешних контрибьюторов. Скорее всего, SQLite используется больше, чем все остальные движки баз данных суммарно. В мире работают миллиарды копий SQLite. Её можно встретить повсюду. https://habr.com/ru/companies/ruvds/articles/873816/ 📲 Мы в MAX #db 👉 @database_info
846
8
Как лучше всего изучать язык SQL? В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40
Как лучше всего изучать язык SQL? В 1986 году язык SQL (Structured Query Language) стал стандартом. В течение последующих 40 лет он стал доминирующим языком для систем управления реляционными базами данных. Чтение последнего стандарта (ANSI SQL 2016) может занять много времени. Как я могу его выучить? В состав языка SQL входят 5 компонентов: - DDL: data definition language, such as CREATE, ALTER, DROP - DQL: data query language, such as SELECT - DML: data manipulation language, such as INSERT, UPDATE, DELETE - DCL: data control language, such as GRANT, REVOKE - TCL: transaction control language, such as COMMIT, ROLLBACK Для бэкенд-инженера может потребоваться знание большинства из них. Аналитику данных может потребоваться хорошее понимание DQL. Выберите те темы, которые наиболее актуальны для вас. 📲 Мы в MAX #db 👉 @database_info
809
9
Шардирование базы данных на пальцах Популярные приложения рано или поздно должны масштабироваться для ускорения доступа к дан
Шардирование базы данных на пальцах Популярные приложения рано или поздно должны масштабироваться для ускорения доступа к данным и увеличения трафика. Чтобы распределить данные на несколько серверов и обеспечить им безопасность и целостность, нужна база данных с соответствующей архитектурой — шардированная база данных. Шардирование (шардинг) базы данных — это деление данных на разные фрагменты с целью повышения производительности и надежности. Иногда это понятие путают с репликацией и партицированием, но на самом деле это разные направления масштабирования, которые могут быть реализованы в пределах одной базы данных. Существует два вида шардирования: ▪Вертикальное (по столбцам): каждый шард содержит часть столбцов массива и все связанные с ними строки данных. ▪Горизонтальное (по каким-либо критериям строки): каждый шард содержит одинаковые столбцы, но разные строки данных. https://architecturenotes.co/database-sharding-explained/ 📲 Мы в MAX #db 👉 @database_info
857
10
Визуализация SQL-запроса 📲 Мы в MAX #db 👉 @database_info
Визуализация SQL-запроса 📲 Мы в MAX #db 👉 @database_info
815
11
🚀 Подборка полезных 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 Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса) Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии в IT📌 https://max.ru/progjob https://max.ru/channel_rabotait Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Городские📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП https://max.ru/channel_krasnodar_novosty Краснодар Новости https://max.ru/channel_novosibirsk_novosti Новосибирск https://max.ru/channel_samara_novosti Новости Самары https://max.ru/channel_ekaterinburg_novosti Новости Екатеринбурга https://max.ru/channel_kazan_novosti Новости Казани https://max.ru/channel_omsk_novosti Новости Омска https://max.ru/channel_moskva_24 Москва 24
728
12
7 SQL-запросов, которые решают 90% всех задач на работе Каждый день одно и то же. Открываешь клиент базы данных, чтобы что-то
7 SQL-запросов, которые решают 90% всех задач на работе Каждый день одно и то же. Открываешь клиент базы данных, чтобы что-то проверить, посчитать или найти. И снова пишешь почти тот же SELECT, что и вчера, с тем же WHERE и JOIN. Знакомо? SQL в большинстве случаях не требует сложные 100-строчные запросы с вложенными подзапросами на три уровня глубины. Чаще всего нам нужны простые, отточенные и, главное, эффективные конструкции. В этой статье я собрал 7 таких запросов-«рабочих лошадок». Это не какой-то там справочник, а готовая шпаргалка для реальных задач. https://habr.com/ru/companies/timeweb/articles/943298/ 📲 Мы в MAX #db 👉 @database_info
892
13
Продвинутый курс SQL за час - проще некуда Сегодня я продолжу рассказывать про SQL и мы погрузимся уже в чуть более интересны
Продвинутый курс SQL за час - проще некуда Сегодня я продолжу рассказывать про SQL и мы погрузимся уже в чуть более интересные запросы, связи и я попробую рассказать максимально просто о связях join и о группировках, на мой взгляд две не самые простые темы. Содержание: 00:00 - Поехали 01:14 - Сортировка по номеру 03:23 - Ограничение вывода limit 06:30 - Уникальность данных distinct 08:18 - Сложение колонок 11:00 - Псевдонимы 15:35 - join - связи таблиц 27:45 - Left join 29:38 - Right join 35:00 - Быть или не быть (exists) 39:32 - Объединения union 41:42 - Глобальный поиск 43:45 - Агрегатные функции 54:00 - Группировка данных group by источник 📲 Мы в MAX #db #SQL 👉 @database_info
988
14
Типы JOIN в SQL и когда их применять - INNER JOIN - пересечение множеств (только совпавшие строки). - LEFT JOIN - все слева + совпавшие справа (несовпавшие → NULL). - RIGHT JOIN - симметричен LEFT, лучше переворачивать под LEFT. - FULL OUTER JOIN - все слева и справа (где нет пары → NULL). - CROSS JOIN — декартово произведение (каждая со всеми). - SELF JOIN - таблица соединяется сама с собой. - SEMI / ANTI JOIN - “есть/нет соответствия” (через EXISTS / NOT EXISTS). - LATERAL / APPLY - зависимая подзапросная таблица на строку слева. 1️⃣ INNER JOIN - «строго есть пара» «Покажи оплаченные заказы с данными клиента». SELECT o.id, c.name FROM orders o JOIN customers c ON c.id = o.customer_id WHERE o.status = 'paid'; Используйте, когда отсутствие пары - повод исключить строку. 2️⃣ LEFT JOIN - «все слева, даже без пары» «Список клиентов и количество их заказов (включая с нулём)». SELECT c.id, c.name, COALESCE(COUNT(o.id), 0) AS orders_cnt FROM customers c LEFT JOIN orders o ON o.customer_id = c.id GROUP BY c.id, c.name; По умолчанию для «обогащения» справочниками и опциональных связей. 3️⃣ RIGHT JOIN - почти не нужен Заменяйте на LEFT, поменяв стороны: -- было: -- SELECT ... FROM A RIGHT JOIN B ON ... -- стало: SELECT ... FROM B LEFT JOIN A ON ... 4️⃣ FULL OUTER JOIN - «объединить всё» «Свод по всем клиентам и всем заказам, даже если без пары». SELECT COALESCE(c.id, o.customer_id) AS customer_key, c.name, o.id AS order_id FROM customers c FULL JOIN orders o ON o.customer_id = c.id; Редко нужен в отчётах/сверках. Поддержка зависит от СУБД. 5️⃣ CROSS JOIN - «все комбинации» «Собрать сетку метрик по всем регионам и кварталам». SELECT r.region, q.quarter FROM regions r CROSS JOIN quarters q; Осторожно: взрыв строк. 6️⃣ SELF JOIN - «сравнить строки внутри таблицы» «Найти менеджера и его подчинённого». SELECT e.name AS employee, m.name AS manager FROM employees e LEFT JOIN employees m ON m.id = e.manager_id; 7️⃣ SEMI JOIN (EXISTS) - «фильтрация по факту наличия» «Клиенты, у кого были заказы за 30 дней». SELECT c.* FROM customers c WHERE EXISTS ( SELECT 1 FROM orders o WHERE o.customer_id = c.id AND o.created_at >= CURRENT_DATE - INTERVAL '30 day' ); Не размножает строки, часто быстрее, чем JOIN + DISTINCT. 8️⃣ ANTI JOIN (NOT EXISTS) - «кто без соответствий» «Товары, которые ни разу не покупали в этом году». SELECT p.* FROM products p WHERE NOT EXISTS ( SELECT 1 FROM order_items oi JOIN orders o ON o.id = oi.order_id WHERE oi.product_id = p.id AND o.created_at >= date_trunc('year', CURRENT_DATE) ); Избегайте NOT IN с NULL - может дать пустой результат. 9️⃣ LATERAL / APPLY - «топ-N на строку» «Последний заказ на клиента» (PostgreSQL: LATERAL, SQL Server: APPLY). SELECT c.id, c.name, o_last.id AS last_order_id FROM customers c LEFT JOIN LATERAL ( SELECT o.id FROM orders o WHERE o.customer_id = c.id ORDER BY o.created_at DESC LIMIT 1 ) o_last ON true; 💡Подводные камни - LEFT JOIN + фильтр в WHERE ⇒ превращается в INNER. Если нужно оставить «без пары», переносите условие в ON: -- ❌ неверно SELECT ... FROM c LEFT JOIN o ON o.customer_id = c.id WHERE o.status = 'paid'; -- ✅ верно SELECT ... FROM c LEFT JOIN o ON o.customer_id = c.id AND o.status = 'paid'; - Дубликаты из «один-ко-многим». Перед JOIN делайте агрегацию в подзапросе/CTE. - Индексы на ключах соединений (FK и соответствующие PK/UK) - must. - Сопоставимость типов/колляций. Функции на ключе (LOWER(col)) ломают sargability - лучше нормализовать данные заранее. - EXISTS чаще лучше, чем JOIN + DISTINCT для фильтрации. - Проверяйте план. EXPLAIN (ANALYZE, BUFFERS) и сравнение альтернатив. Сохрани, чтобы не забыть. А как вы чаще фильтруете - через JOIN+DISTINCT или EXISTS? 📲 Мы в MAX #db #SQL 👉 @database_info
1 024
15
Антипаттерн: N+1 запросов — как заметить и починить Вы берёте список сущностей, а потом в цикле для каждой тянете связанные данные. В итоге - 1 запрос за «родителями» + N запросов за «детьми». Латентность растёт линейно от размера выборки. Симптомы - В логах много одинаковых коротких запросов. - Кол-во запросов ≈ размеру списка. - Страница/endpoint сильно «замедляется» при росте данных. Плохой пример (SQL + псевдокод) -- Берём пользователей SELECT id, name FROM users WHERE active = true; -- Потом в цикле по каждому: SELECT count(*) FROM orders WHERE user_id = :id; Правильно (SQL, PostgreSQL) — сетевое мышление: SELECT u.id, u.name, count(o.*) AS orders_cnt FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.active = true GROUP BY u.id, u.name; Django ORM # Плохо: в шаблоне/цикле обращаемся к user.orders -> N+1 users = User.objects.filter(active=True) # Хорошо: подгрузим связи заранее users = (User.objects .filter(active=True) .prefetch_related('orders')) # для 1:N # для 1:1 / ForeignKey используйте select_related('profile') # Агрегация без цикла from django.db.models import Count users = (User.objects.filter(active=True) .annotate(orders_cnt=Count('orders'))) SQLAlchemy from sqlalchemy.orm import selectinload, joinedload # 1:N — безопаснее selectinload (батчирует IN (...)) users = (session.query(User) .options(selectinload(User.orders)) .filter(User.active.is_(True)) .all()) # 1:1 — joinedload user = (session.query(User) .options(joinedload(User.profile)) .get(user_id)) Практические советы - Логируйте кол-во запросов на эндпойнт/страницу. В Django - django-debug-toolbar, assertNumQueries в тестах; в SQLAlchemy - echo/интеграция с логгером. - Индексы: обязательно orders(user_id); если фильтруете по статусу - составной (user_id, status). - Батчинг вместо циклов: тяните детей одним запросом WHERE user_id IN (...), затем мапьте в памяти. - Осторожно с joinedload для 1:N на больших выборках - риск «взрыва» строк. Для 1:N чаще выбирайте selectinload. - Колонки по делу: не тащите SELECT *, берите только нужные поля. - Пагинация: уменьшает N и давление на сеть/память. - EXPLAIN (ANALYZE, BUFFERS) - проверяйте планы и кардинальности. 💡Думайте наборами, а не циклами. Eager loading + агрегаты закрывают 90% случаев N+1. Настройте мониторинг количества запросов - и ловите проблему до продакшена. Сохрани, чтобы не наступить снова. Поделись с коллегами. А как вы ловите N+1 у себя? 📲 Мы в MAX #db 👉 @database_info
890
16
⚔️ SQL vs NoSQL: Что выбрать для вашего проекта? Выбор базы данных - одно из ключевых архитектурных решений. Нет универсально
⚔️ SQL vs NoSQL: Что выбрать для вашего проекта? Выбор базы данных - одно из ключевых архитектурных решений. Нет универсальной "серебряной пули", есть инструменты под разные задачи. Давайте разберем основные отличия и когда что использовать. 🐘 SQL (Реляционные БД): Порядок и Транзакции Примеры: PostgreSQL, MySQL, MS SQL, Oracle. Основа: жесткая схема данных, таблицы, строки, отношения, поддержка ACID транзакций (атомарность, согласованность, изолированность, долговечность). -- SQL Пример: JOIN трех таблиц SELECT u.name, o.order_date, p.product_name FROM users u JOIN orders o ON u.id = o.user_id JOIN order_items oi ON o.id = oi.order_id JOIN products p ON oi.product_id = p.id WHERE u.country = 'KZ'; Выбирайте SQL, если: • У вас четко структурированные данные. • Критична согласованность данных и сложные транзакции (например, финтех). • Требуются сложные выборки и отчеты (мощный диалект SQL). 🍃 NoSQL: Гибкость и Масштабирование Примеры: MongoDB (документная), Redis (ключ-значение), Cassandra (ширококолоночная), Neo4j (графовая). Основа: гибкая схема или ее отсутствие, различные модели данных, фокус на горизонтальном масштабировании. Часто жертвуют полной ACID согласованностью ради производительности (Eventual Consistency). // NoSQL Пример (MongoDB): вставка документа пользователя db.users.insertOne({ name: "Aliya", age: 28, address: { city: "Almaty", street: "Abay Ave" }, tags: ["dev", "database"] }); Выбирайте NoSQL, если: • Данные неструктурированы или их структура часто меняется. • Требуется огромная пропускная способность записи/чтения (лайки, логи, чаты). • Необходимо простое горизонтальное масштабирование (добавление новых узлов). • Допустима отложенная согласованность (Eventual Consistency). Подводные камни NoSQL: • Сложность JOIN-ов: В документных БД (как MongoDB) JOIN-ы (lookup) дорогие и не так эффективны, как в реляционных. Модель данных часто приходится "денормализовать" (дублировать данные). • Отложенная согласованность: Если вам критично видеть самое последнее записанное значение сразу после записи, будьте осторожны с NoSQL конфигурациями по умолчанию. Итог: Выбирайте инструмент под задачу. SQL - для транзакций и структуры, NoSQL - для масштаба и гибкости. Часто в современном мире используют полиглот-архитектуру: SQL для ядра данных, а NoSQL для кэширования (Redis) или хранения логов/аналитики. Сохрани пост, чтобы освежить в памяти перед проектированием следующей системы! 👇 📲 Мы в MAX #db 👉 @database_info
701
17
🚀 Подборка полезных 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 Типичный Сисадмин https://max.ru/channel_win_sysadmin Системный Администратор Windows https://max.ru/channel_linux_admin Linux: Системный администратор https://max.ru/channel_linuxmod Linux https://max.ru/channel_i_linux Системный администратор https://max.ru/channel_devopslib DevOps, SRE, Sysadmin https://max.ru/channel_devops_star DevOps Star (Звезда Девопса) Excel лайфхак 📌 https://t.me/Excel_lifehack Excel лайфхак Английский с нуля 🇬🇧 https://max.ru/UchuEnglish 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С https://max.ru/channel_DevLab1C 1С:Предприятие 8 Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика https://max.ru/channel_cpp_geek C++ geek Программирование Go📌 https://max.ru/golang_lib Библиотека Go (Golang) разработчика Программирование React📌 https://max.ru/react_lib React Программирование Rust📌 https://max.ru/channel_rust_lib Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика https://max.ru/channel_java_geek Java Geek GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии в IT📌 https://max.ru/progjob https://max.ru/channel_rabotait Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы https://max.ru/piterspb Питер Новости: Санкт-Петербург / СПБ / ДТП
742
18
🔥 Неправильные типы данных в БД — тихий убийца производительности Одна из самых частых ошибок — выбирать тип “на всякий случ
🔥 Неправильные типы данных в БД — тихий убийца производительности Одна из самых частых ошибок — выбирать тип “на всякий случай побольше”. ❌ Примеры антипаттернов: - VARCHAR(255) для всего подряд, даже если поле — код из 10 символов. - TEXT для email-адресов. - BIGINT для счётчика, где максимум 1000 записей. - FLOAT для денег (теряешь точность). ✅ Как лучше: - Размер строки под задачу: VARCHAR(50) для email, CHAR(2) для кода страны. - Для денег → NUMERIC(10,2) или DECIMAL. - Для булевых значений → BOOLEAN, а не INT. - Для дат → DATE или TIMESTAMP, а не строка. 📌 Пример: -- Плохо price FLOAT; -- Хорошо price NUMERIC(10,2); ⚡️ Итог: грамотный выбор типов = меньше места, быстрее запросы, меньше багов. Сохрани, чтобы не забыть 😉 📲 Мы в MAX #db 👉 @database_info
809
19
🏁До старта обработки миллиарда записей 3… 2… 1… клик Выбирайте не просто СУБД, а гоночный болид для работы с данными. ClickH
🏁До старта обработки миллиарда записей 3… 2… 1… клик Выбирайте не просто СУБД, а гоночный болид для работы с данными. ClickHouse® в облаке Selectel — машина, адаптированная под предельные нагрузки и сложные трассы. Отлично работает с векторными типами данных, эффективна в запросах для задач поиска семантического сходства, кластеризации или RAG. Под капотом — SSD-накопители стандарта NVMe, оперативная память DDR5 и процессоры Intel® Xeon®Gold и AMD EPYC™. Мощное железо для максимальной производительности вашей баз данных. Пройдемся по базе. Что вас ждет после запуска кластера ClickHouse в облаке Selectel? ⚡Скорость. Кластеры рассчитаны на хранение и быструю обработку даже петабайтов данных и обработку тяжелых аналитических запросов. ⚡Надежность. В Multi-AZ кластерах ноды размещены в разных дата-центрах, чтобы инфраструктура продолжила работу даже при отключении одного из узлов. ⚡Экономичный расход. Может выполнять запросы к данным, хранящимся в S3 в формате Iceberg, без их копирования. Это позволяет сократить расходы более чем в два раза по сравнению с использованием только локальных дисков. На вас — пилотирование, а обслуживание кластера забирает на себя Selectel. Ускорьте работу с базами данных в облаке Selectel: https://slc.tl/ywhx8 Реклама. АО "Селектел". erid:2W5zFJF5Fkm
875
20
🚨 Антипаттерн: Почему OFFSET убивает твою базу (и как делать пагинацию правильно) Привет! Если вы когда-нибудь реализовывали
🚨 Антипаттерн: Почему OFFSET убивает твою базу (и как делать пагинацию правильно) Привет! Если вы когда-нибудь реализовывали каталог товаров или ленту новостей, то наверняка писали запрос с LIMIT и OFFSET. Для небольших таблиц это работает отлично, но как только проект взлетает и данных становится много, база начинает задыхаться. Давайте разберем, почему так происходит и как это лечить. ❌ Как мы делаем обычно: SELECT id, title, created_at FROM articles ORDER BY created_at DESC LIMIT 50 OFFSET 100000; В чем подвох? База данных не умеет «магически» прыгать на 100 000-ю строку. Ей придется прочитать, отсортировать (если нет подходящего индекса) и отбросить первые 100 000 строк, чтобы вернуть вам всего 50. Чем глубже пользователь листает страницы, тем медленнее работает запрос. Нагрузка на CPU и диски растет экспоненциально. ✅ Как делать правильно: Вместо того чтобы говорить базе «пропусти N строк», мы говорим ей «дай мне 50 записей, которые идут сразу после последней записи, которую я уже видел». SELECT id, title, created_at FROM articles WHERE created_at < '2023-10-25 14:00:00' -- дата из последней записи на предыдущей странице ORDER BY created_at DESC LIMIT 50; Этот запрос мгновенно найдет нужное место по индексу (B-Tree) и прочитает ровно 50 строк. Никакой лишней работы! 🛠 Важный нюанс: Если поле created_at не уникально (две статьи вышли в одну секунду), предыдущий запрос может пропустить данные. Используйте уникальный «тайбрейкер» - например, id. В PostgreSQL это можно сделать очень элегантно с помощью кортежей (Row Values): SELECT id, title, created_at FROM articles WHERE (created_at, id) < ('2023-10-25 14:00:00', 10543) ORDER BY created_at DESC, id DESC LIMIT 50; (Не забудьте создать составной индекс: `CREATE INDEX idx_articles_created_id ON articles (created_at DESC, id DESC);`) 📌 Итог: • OFFSET / LIMIT: Ок для админок с небольшим трафиком и малым объемом данных (до ~10-50к строк). • Keyset Pagination: Must-have для бесконечных скроллов (infinite scroll), публичных API и таблиц на миллионы записей. 👇 Скинь ссылку на этот пост фронтендеру, который просит «просто добавить номер страницы» в API. А какой метод пагинации чаще всего используете вы в своих текущих проектах? Делитесь в комментариях! 📲 Мы в MAX #db 👉 @database_info
843