SQL Portal | Базы Данных
Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных Связь: @devmangx РКН: https://clck.ru/3H4Wo3
Ko'proq ko'rsatish📈 Telegram kanali SQL Portal | Базы Данных analitikasi
SQL Portal | Базы Данных (@sqlportal) kanali faol ishtirokchi. Hozirda hamjamiyat 13 952 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 9 090-o'rinni va Rossiya mintaqasida 47 104-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 13 952 obunachiga ega bo‘ldi.
27 Iyul, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -121 ga, so‘nggi 24 soatda esa -6 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 10.62% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 5.11% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 482 marta ko‘riladi; birinchi sutkada odatda 714 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 5 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent строка, sql, индекс, postgres, колонка kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Присоединяйтесь к нашему каналу и погрузитесь в мир баз данных
Связь: @devmangx
РКН: https://clck.ru/3H4Wo3”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 28 Iyul, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
INSERT INTO ... SELECT.
Но главный урок оказался вовсе не в синтаксисе SQL.
Я столкнулся с классической ошибкой новичков. Исходная таблица использовала стиль именования PascalCase (TransactionAmount), а новую таблицу я создал в snake_case (transaction_amount).
Из-за этого мои запросы постоянно выдавали ошибки.
В итоге я понял важное правило: в операторе SELECT всегда нужно обращаться к именам столбцов именно так, как они называются в исходной таблице, независимо от того, как эти столбцы названы в таблице назначения.
👉 @SQLPortalapple banana cherryвы можете получить:
Apple Banana apple bananaХотя слова одинаковые, порядок отличается. Почему так происходит? Некоторые базы данных рассматривают прописные и строчные буквы как разные символы при сортировке, поэтому слова с заглавной буквы могут отображаться раньше слов со строчной. Как отключить чувствительность к регистру? В SQLite для этого можно использовать
COLLATE NOCASE:
SELECT *
FROM users
ORDER BY name COLLATE NOCASE;
Так SQL будет сортировать значения без учёта регистра, не изменяя сами данные.
Если результаты ORDER BY выглядят странно, первым делом проверьте настройки collation — именно они часто определяют, как база данных сравнивает и сортирует текст.
👉 @SQLPortalSELECT NULLIF(10, 10);
Результат:
NULLПоскольку оба значения одинаковые,
NULLIF() возвращает NULL.
Функция особенно полезна, когда нужно избежать ошибки деления на ноль или заменить определённое значение на NULL для дальнейшей обработки.
👉 @SQLPortalORDER BY с несколькими столбцами база данных сначала сортирует весь результат по первому указанному столбцу (в данном примере — sales).
В результате образуются группы строк с одинаковыми значениями. Например, Mira и Bob оказываются в одной группе, потому что у обоих значение sales равно 12 000.
После этого применяется сортировка по второму столбцу, которая служит для разрешения совпадений внутри каждой такой группы.
Поскольку второй столбец — age, а сортировка выполняется по возрастанию (ASC), сначала будет выведена Mira (30 лет), а затем Bob.
Тот же принцип применяется ко всем строкам, у которых совпадают значения первого столбца сортировки.
Что если совпадают значения и во втором столбце? Если одинаковыми оказываются значения и второго столбца, всё зависит от конкретной СУБД. Некоторые базы данных, особенно при работе с небольшими наборами данных, могут сохранить порядок вставки записей как дополнительный критерий сортировки.
Однако в большинстве случаев, особенно при работе с большими и сложными таблицами, порядок строк с полностью одинаковыми значениями сортируемых столбцов не гарантируется и может быть произвольным.
Совет: если вам важен полностью предсказуемый порядок результатов, всегда добавляйте в ORDER BY дополнительный столбец с уникальными значениями (например, id). Это обеспечит стабильную и воспроизводимую сортировку.
👉 @SQLPortalWHERE и HAVING.
Запомните простое правило:
• WHERE фильтрует отдельные строки.
• HAVING фильтрует уже сгруппированные результаты.
Пример
WHERE salary > 50000
Отбирает строки до выполнения группировки.
HAVING COUNT(*) > 5
Отбирает группы после выполнения GROUP BY.
Запомните порядок выполнения SQL-запроса
WHERE → GROUP BY → HAVING
Или проще:
• WHERE — сначала;
• GROUP BY — группировка;
• HAVING — после группировки.
Если SQL кажется сложным, проблема чаще всего не в самом запросе, а в непонимании порядка его выполнения.
Освойте этот принцип один раз — и работа с JOIN, агрегатными функциями и аналитическими отчётами станет намного понятнее.
👉 @SQLPortalINNER JOIN — возвращает только совпадающие записи из обеих таблиц. Это самый простой и безопасный вариант соединения.
• LEFT JOIN — возвращает все записи из левой таблицы и совпадающие записи из правой.
Если совпадений нет, данные из правой таблицы будут иметь значение NULL.
LEFT JOIN особенно полезен при построении отчётов, когда нужно сохранить все записи из основной таблицы, даже если связанные данные отсутствуют.
👉 @SQLPortalJOIN.
Вместо множества соединений таблиц можно описать путь через данные, например:
Клиент → купил → товар ← купил ← похожий клиент → подписан на → брендТакой подход делает сложные запросы более понятными и приближает PostgreSQL к возможностям специализированных графовых СУБД. Где это может пригодиться? • Рекомендательные системы — поиск пользователей с похожими интересами и рекомендация товаров. • Контроль доступа — анализ цепочек ролей, групп и разрешений. • Выявление мошенничества — поиск подозрительных связей между пользователями, устройствами, платежами и аккаунтами. • Графы знаний (Knowledge Graphs) — моделирование сложных взаимосвязей между сущностями. • AI и LLM — предоставление языковым моделям дополнительного контекста за счёт анализа связанных данных. Появление графовых запросов — один из самых интересных шагов в развитии PostgreSQL. Теперь многие задачи, которые раньше требовали использования отдельной графовой базы данных, можно будет решать непосредственно в PostgreSQL. 👉 @SQLPortal
