📕 Борьба с блокировками в PostgreSQL и MS SQL Server для администраторов баз данных, Data engineers, Backend и FullStack-разработчиков.

Как вести работу c PostgreSQL и MS SQL Server без конфликтов и дедлоков.

📗 На вебинаре 20 мая в 20:00 мск разберём:
1. Всё о различных типах блокировок и их механизмах, сходвстах и различиях;
2. Методы предотвращения и разрешения дедлоков;

📘 В результате на практике освоите написание SQL-кода, минимизирующего риски блокировок и дедлоков.

👉 Регистрация и подробности о курсе Базы данных: https://vk.cc/cM56It

Все участники открытого урока получат скидку на курс "Базы данных"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Читать полностью…

PostgreSQL или MySQL?

Один из самых частых вопросов от разработчиков и DevOps — “Что лучше: PostgreSQL или MySQL?”. Давай без фанатизма, просто по фактам 👇

🔷 PostgreSQL:

* Поддержка JSONB с индексами — почти как NoSQL внутри SQL
* CTE, оконные функции, полнотекстовый поиск — топ для аналитики
* Расширяемость: можно писать свои типы, функции, операторы
* Хорош для сложных запросов, аналитики, геоданных (PostGIS)

🔻 Минусы:
– Сложнее в настройке и оптимизации
– Меньше хостингов out-of-the-box (но всё быстро меняется)



🔶 MySQL (особенно InnoDB / MariaDB):

* Быстрее на простых SELECT/INSERT, если запросы примитивные
* Больше ready-to-go хостингов и тулов для web
* Низкий порог входа — быстрее поднимается новичками

🔻 Минусы:
– Слабее в сложных SQL-конструкциях
– Нет нормальной поддержки CTE до недавнего времени
– JSON без индексации (в MySQL < 8.0)



Вывод:
🧠 Если делаешь CRM, веб-продукт или MVP с простыми запросами — MySQL зайдёт.
📊 Если строишь data-heavy приложения, BI, ETL или гео-системы — PostgreSQL без шансов.

Какой используешь ты и почему? 👇

#db

👉 @database_info

Читать полностью…

Как упростить хранение логов и работу с данными?

В помощь отделу ИБ, DevOps- и SRE-инженерам, дата-аналитикам и разработчикам Selectel предлагает облако для OpenSearch.

Вы сможете создать готовый к работе кластер OpenSearch за несколько минут. Это поможет быстро найти, визуализировать и проанализировать данные, события или метрики без ограничений в масштабируемости.

Кроме производительного железа, бесперебойной работы и быстрого масштабирования в облаке Selectel для OpenSearch вы получите:

● бесплатные автоматические бекапы,
● возможность использовать диски разной производительности для холодного и горячего хранения
● Dashboard из коробки для аналитики и управления

Создайте кластер в OpenSearch за несколько кликов в Selectel по ссылке: https://slc.tl/yc44k

Реклама. АО «Селектел», ИНН 7810962785, ERID: 2VtzquyU6q2

Читать полностью…

Мини-гайд: Как ускорить SELECT’ы в PostgreSQL с помощью покрытия индекса (covering index)

Иногда индекс есть, а запрос всё равно тормозит. Почему?

👉 Потому что обычный индекс помогает найти строку, но потом БД всё равно лезет в таблицу, чтобы достать нужные поля. Это называется heap access — и это дорого.

📌 Решение — покрывающий индекс. Это индекс, который содержит все нужные поля прямо в себе. PostgreSQL с версии 11 умеет делать это через INCLUDE.

🔧 Пример:

-- Запрос
SELECT name, email FROM users WHERE status = 'active';

-- Обычный индекс
CREATE INDEX idx_users_status ON users(status);

-- Покрывающий индекс
CREATE INDEX idx_users_status_cover ON users(status) INCLUDE (name, email);

✅ Теперь PostgreSQL может ответить на запрос только по индексу, не трогая таблицу → быстрее.

📈 Особенно заметный профит:
– На больших таблицах
– В OLTP-нагрузках (много коротких запросов)
– Когда важна задержка ответа (например, API)

⚠️ Но не стоит включать весь ряд в индекс — это увеличит размер и замедлит обновления.

Вывод:
Покрывающие индексы — мощный способ ускорить SELECT без изменения запроса. Используй их там, где читаешь часто, а пишешь редко.

Сохрани, пригодится при оптимизации ⚙️

#db

👉 @database_info

Читать полностью…

🧱 Антипаттерн: Ненормализованная схема в SQL

Когда нужно «быстро запилить фичу», руки тянутся сделать одну таблицу, где и заказ, и клиент, и товары — всё в куче.

Пример:

CREATE TABLE orders (
  order_id SERIAL PRIMARY KEY,
  customer_name TEXT,
  customer_email TEXT,
  product_1_name TEXT,
  product_1_price NUMERIC,
  product_2_name TEXT,
  product_2_price NUMERIC
);

😰 Что пойдет не так:

– Дублирование данных — имя клиента повторяется в каждом заказе.
– Нет масштабируемости — максимум 2 продукта? А если будет 3?
– Трудности с запросами — попробуй посчитать топ-5 товаров. Удачи.
– Адские апдейты — изменить email клиента надо во всех заказах.

✅ Как правильно:

1. Нормализуй. Раздели данные на сущности: customers, orders, products, order_items.
2. Используй внешние ключи.
3. Не бойся JOIN'ов — они для этого и придуманы.

Пример нормализованной структуры:

-- Таблица клиентов
CREATE TABLE customers (
  id SERIAL PRIMARY KEY,
  name TEXT,
  email TEXT
);

-- Таблица заказов
CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  customer_id INT REFERENCES customers(id)
);

-- Таблица товаров
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT,
  price NUMERIC
);

-- Связка товаров и заказов
CREATE TABLE order_items (
  order_id INT REFERENCES orders(id),
  product_id INT REFERENCES products(id),
  quantity INT
);

📌 Да, нормализация требует чуть больше времени. Зато потом вы не утонете в хаосе.

Сохрани, чтобы не забыть — и не повторять чужих ошибок.

#db

👉 @database_info

Читать полностью…

Столкнулись с падением производительности базы данных?
Не делайте резких движений: вы можете ухудшить ситуацию.

Сначала нужно верно диагностировать причину проблемы.
Возможно вы неправильно выбрали индексы, а быть может дело вообще в самой архитектуре БД – вариантов масса!

На открытом вебинаре «Как ускорить работу и повысить надёжность PostgreSQL»
вы узнаете:
🎯как обеспечить высокую производительность и отказоустойчивость базы данных
🎯как вовремя выявить деградацию производительности с помощью диагностики

Вебинар проведёт Дмитрий Золотов, Kotlin-разработчик в «Яндексе».

Приглашаем технических руководителей, админов БД, девопсов и разработчиков.

Все участники получат в подарок видеоурок «Безопасность в PostgreSQL: защита данных, управление доступом и аудит» и скидку 7% на любой курс OTUS.

6 мая, 19:00 МСК
Бесплатно
Записаться - https://otus.pw/hhGc/

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFGBtxnU

Читать полностью…

Антипаттерн: «Одна таблица на всё»

Когда бизнес-логика усложняется, а структура БД остаётся в духе Excel — жди беды.

🔴 Что это такое?
Проектировщик (часто на раннем этапе) создаёт одну большую таблицу, где:
– сотни колонок на все случаи жизни,
– куча NULL-ов,
– смешаны данные разных сущностей (например, и клиенты, и заказы, и статусы).

Так проще… пока не начнётся работа с реальными данными.

💥 Что пойдёт не так:
– Производительность падает: индексы не работают эффективно.
– Сложность валидации и бизнес-логики.
– Трудно расширять: каждое изменение — как операция на открытом сердце.
– Нельзя нормально нормализовать: всё связано со всем.

✅ Как избежать:
– Используй нормализацию: выноси повторяющиеся и логически независимые данные в отдельные таблицы.
– Не бойся JOIN-ов — это не зло, а инструмент.
– Планируй схему БД под задачи, а не наоборот.

📌 Пример:
Плохо:

CREATE TABLE everything (
  id INT,
  client_name TEXT,
  order_price DECIMAL,
  order_status TEXT,
  delivery_address TEXT,
  ...
);

Хорошо:

CREATE TABLE clients (
  id INT PRIMARY KEY,
  name TEXT
);

CREATE TABLE orders (
  id INT PRIMARY KEY,
  client_id INT REFERENCES clients(id),
  price DECIMAL,
  status TEXT
);

📎 Вывод: одна таблица ≠ проще. Это короткий путь к хаосу.
Разделяй и властвуй.

Сохрани, чтобы не пришлось рефакторить через полгода 👇

#db

👉 @database_info

Читать полностью…

❌ Антипаттерн: Хранить даты и время в VARCHAR

Встречали такое?

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  order_date VARCHAR(20)
);

На первый взгляд — всё ок: дата есть, строка хранит. Но на практике — сплошные проблемы:

🔴 Нет гарантии формата
'2024-12-01', '12/01/2024', '01.12.24', 'вчера' — всё ляжет, но работать с этим потом боль.

🔴 Сложность фильтрации и сортировки
Сравнение строк ≠ сравнение дат.
Запросы типа WHERE order_date > '2024-01-01' могут вести себя непредсказуемо.

🔴 Нельзя использовать функции времени
Ни DATE_TRUNC, ни AGE(), ни агрегаты по времени не работают нормально с VARCHAR.

✅ Как правильно
Используйте типы DATE, TIMESTAMP, TIMESTAMPTZ — они:

* валидируют данные на вставке;
* дают мощный инструментарий для анализа;
* упрощают работу с часовыми поясами и интервалами.

CREATE TABLE orders (
  id SERIAL PRIMARY KEY,
  order_date TIMESTAMPTZ DEFAULT now()
);

💡 Если данные приходят в виде строк — парси их при загрузке, а не храни как есть.


Сохрани, чтобы не наступить на эти же грабли ☝️
А как у вас хранят даты?

#db

👉 @database_info

Читать полностью…

Сегодня я хочу рассказать вам про одну часто недооцененную фишку в PostgreSQL — partial indexes (частичные индексы).

Обычно мы создаём индексы на всю таблицу, но что если нам нужно ускорить только небольшую часть данных? Например, часто выбираются только активные пользователи (status = 'active'). Вместо полного индекса можно создать индекс только для нужного поднабора данных:

CREATE INDEX idx_active_users
ON users (last_login)
WHERE status = 'active';

Что это даёт:
- Индекс меньше по размеру → быстрее поиск и обновление.
- Используется только тогда, когда запрос соответствует условию status = 'active'.
- Меньше нагрузка на диск при обновлениях таблицы.

🛠 Где это реально помогает:
- Таблицы с миллионами записей, где активно работают только с частью строк.
- Сценарии "горячих" и "холодных" данных.

Рекомендую попробовать partial indexes там, где обычные индексы слишком тяжелы или тормозят обновления!

#db

👉 @database_info

Читать полностью…

🚀 Сегодня я покажу вам один из моих любимых хаков для PostgreSQL – генерация серий дат без циклов и хранимок. Это идеальный способ быстро собрать таймлайн для аналитики или отчётов.

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

Вот как это делается с помощью generate_series:

SELECT generate_series(
    date_trunc('day', current_date) - interval '30 days',
    date_trunc('day', current_date),
    interval '1 day'
) AS day;

💡 Результат — 31 строка с датами от 30 дней назад до сегодняшнего дня.

Теперь добавим, например, LEFT JOIN к таблице events, чтобы увидеть активность по дням:

SELECT
    d.day,
    COUNT(e.id) AS events_count
FROM
    generate_series(
        date_trunc('day', current_date) - interval '30 days',
        date_trunc('day', current_date),
        interval '1 day'
    ) AS d(day)
LEFT JOIN events e ON date_trunc('day', e.created_at) = d.day
GROUP BY d.day
ORDER BY d.day;

📊 Отлично подходит для дашбордов, когда нужно увидеть, где были дни без событий.

Пользуетесь ли вы generate_series? А может быть, используете что-то подобное в других СУБД? Делитесь в комментариях👇

#db

👉 @database_info

Читать полностью…

Антипаттерн: NULL в WHERE — и ты в ловушке

Когда в таблице есть NULL, а в WHERE ты пишешь что-то вроде:

SELECT * FROM users WHERE age != 30;

Ты ожидаешь, что выберутся все, кто не 30.
Но если age IS NULL — такие строки пропадут из выборки!

Почему? Потому что NULL != 30 не TRUE, это UNKNOWN.
А SQL возвращает строки только там, где WHERE → TRUE.

Как избежать?

1. Будь явно осторожен с NULL:

   SELECT * FROM users 
   WHERE age != 30 OR age IS NULL;
   

2. Логика на уровне схемы:
– Если поле нужно всегда — делай NOT NULL.
– Если допускаешь NULL, продумывай поведение выборок.

3. Не верь глазам своим:
Даже count(*) и count(column) ведут себя по-разному из-за NULL.

Вывод:
NULL — это не ноль, не пустая строка и не "ничего".
Это "мы не знаем". И SQL ведёт себя с ним очень осторожно.

Сохрани, чтобы не словить грабли.

#db

👉 @database_info

Читать полностью…

🚨 SELECT * - скрытый враг в проде

На dev-сервере всё шустро. В проде — беда: запросы висят, база потеет. И вроде бы всё ок... пока не заглянешь в SQL:

SELECT * FROM users WHERE status = 'active';

На первый взгляд — удобно. Но:

🔻 Проблемы “SELECT *”:
– Тянет все колонки, даже ненужные. А их может быть 30+.
– Увеличивает нагрузку на сеть и память приложения.
– Ломает кэш — ведь даже малейшие изменения в колонках меняют структуру результата.
– Убивает индекс-only scan: Postgres не может использовать покрывающий индекс, если явно не указаны поля.


✅ Как надо:

🎯 Выбирай только нужные поля:

SELECT id, name, email FROM users WHERE status = 'active';

💡 Хочешь “быстро протестить” в dev-е? Ок. Но не пускай такое в прод. Автоматизируй линтинг SQL, если надо.


Вывод:
SELECT * — это не “удобно”, это дорого. И ты за него уже платишь.

Сохрани, чтобы не словить боль в проде.
А у тебя где последний раз встречалось SELECT *?

#db

👉 @database_info

Читать полностью…

🎯 Мини-гайд
Транзакции в SQLite: просто, но со своими нюансами

SQLite — это встраиваемая база данных, и она немного отличается от привычных серверных СУБД (PostgreSQL, MySQL) в части работы с транзакциями. Но транзакции там есть, и работают по принципу ACID — атомарность, согласованность, изолированность и долговечность.

Разберёмся по полочкам:


🔹 Как начинается и заканчивается транзакция?

BEGIN TRANSACTION;
-- какие-то запросы
COMMIT;

Или, в случае ошибки:

ROLLBACK;

Можно использовать синонимы:
- BEGIN = BEGIN DEFERRED
- BEGIN IMMEDIATE
- BEGIN EXCLUSIVE

Они отличаются уровнем блокировок.


🔹 Типы транзакций

1. DEFERRED (по умолчанию)
🔒 Блокировки ставятся только при первом доступе к таблице (на чтение/запись).

2. IMMEDIATE
🔒 Сразу ставит блокировку на запись (write-lock). Полезно, если точно знаешь, что будешь писать — исключишь гонки.

3. EXCLUSIVE
🔒 Блокирует БД полностью. Даже другие чтения не пройдут.


🔹 Особенности SQLite

- Одна запись за раз: SQLite поддерживает одновременные чтения, но только одну запись одновременно. Остальные получат "database is locked".
- Авто-коммиты: если явно не начать транзакцию — SQLite будет делать коммит после каждого запроса.
- Журналирование: SQLite использует WAL (write-ahead log) или rollback journal — в зависимости от настроек. WAL — более производителен для параллельного чтения.


💡 Советы

- При пакетной вставке всегда оборачивай в транзакцию:

BEGIN;
INSERT INTO users VALUES (...);
INSERT INTO users VALUES (...);
...
COMMIT;

→ Это в разы быстрее, чем отдельные INSERT с автокоммитом.

- Если получаешь ошибку database is locked, проверь:
- Не оставил ли ты открытые транзакции
- Не работают ли несколько процессов с БД одновременно без координации


💬 Вывод: транзакции в SQLite — простые, но критически важные для производительности и корректности. Даже в одиночной БД нужна дисциплина.

Сохрани, чтобы не потерять!

#db

👉 @database_info

Читать полностью…

Когда речь идет о масштабируемости и высокой доступности данных, особенно важно выбрать надежную СУБД.

⭐️ 17 апреля в 12:00 по МСК эксперты УЦСБ и «Газинформсервис» проведут вебинар «Кластерные решения для больших объемов данных: отечественный опыт», на котором продемонстрируют:

▪️Как отечественная СУБД обеспечивает высокую доступность данных в условиях высокой нагрузки
▪️Какими особенностями и преимуществами обладает СУБД Jatoba
▪️Кейсы успешных внедрений
▪️Возможности интерфейса и работу по отказоустойчивости Jatoba DB

Вебинар будет полезен:

▪️Системным администраторам и инженерам, работающим с СУБД и решающим задачи масштабирования и обработки данных
▪️Руководителям проектов и аналитикам, оптимизирующим процессы работы с данными
▪️Топ-менеджерам и IT-директорам, заинтересованным в защите данных и повышении эффективности работы с ними

Регистрация

Реклама. ООО «Уральский центр систем безопасности» ИНН 6672235068 Erid: 2Vtzqufy2PC

Читать полностью…

VACUUM FULL — когда, зачем и с какими рисками

Сейчас поговорим про одну из самых «страшных» команд в арсенале DBA — VACUUM FULL. Она часто спасает, когда база разрослась до неприличных размеров… но может и «уронить» прод, если запустить не вовремя.

Что делает VACUUM FULL?

Он освобождает табличное пространство, физически удаляя "мертвые" строки и переписывая всю таблицу заново. Это не просто очистка, а именно перезапись. Поэтому:

- Таблица полностью блокируется на запись и чтение.
- Используется временное дисковое пространство (вплоть до размера таблицы).
- Может существенно сократить размер базы — особенно, если давно не было очистки.

Когда применять:

- После массового удаления данных.
- Когда обычный VACUUM не помогает уменьшить размер базы.
- При миграции/переезде базы, чтобы максимально уменьшить backup.

Чего опасаться:

- На больших таблицах — это может занять часы.
- Блокировки = пользователи «висят».
- Нужно много свободного места на диске.

Альтернатива: если задача — просто освободить место и база под нагрузкой, рассмотрите pg_repack. Он позволяет делать реорганизацию без блокировок (но требует отдельной установки).

Лично я использую VACUUM FULL только в окне обслуживания или на read replica.

А вы? Когда последний раз делали VACUUM FULL?

#db

👉 @database_info

Читать полностью…

Антипаттерн: SELECT * — удобно, но опасно

Использовать SELECT * — значит звать всех на вечеринку, даже если звал только двоих.

Почему это плохо:
🔹 Излишняя нагрузка на сеть и СУБД — выбираются все столбцы, включая ненужные.
🔹 Проблемы с индексами — СУБД может не использовать покрывающий индекс.
🔹 Ломается при изменении схемы — добавил столбец → внезапно изменилось поведение приложения.
🔹 Сложнее читать и поддерживать — особенно в JOIN’ах.

✅ Как правильно:
Запрашивай только нужные поля:

SELECT id, name, created_at FROM users;

📌 И даже в админках/аналитике лучше явно указывать поля — это дисциплинирует.

Хочешь писать код, который легко масштабировать и отлаживать — забудь про SELECT *.

Сохрани, чтобы не забыть 💾
Поделись с коллегами, которые всё ещё "звёздят" в SQL ✨

#db

👉 @database_info

Читать полностью…

Разбор кейса. Компания переехала с MongoDB на PostgreSQL - зачем и что пошло не так.

Стартап хранил всё в MongoDB — быстро, удобно, JSON-документы летят.
Но через год — бизнес растёт, появляются проблемы:


🔸 Запросы тормозят.
Mongo не любит сложные агрегаты с джойнами по коллекциям.
А бизнесу уже нужно:
– аналитика по заказам
– ретеншн-отчёты
– CRM-связи между сущностями

🔸 Дублирование данных.
Документы растут, становятся вложенными, обновлять — боль.
Классическая проблема: “Обновили e-mail юзера — забыли в двух местах”.

🔸 Сложность поддержки.
Без схемы трудно отследить, что где лежит. Новым разработчикам — боль.


🔁 Решение: PostgreSQL

– Явная схема → валидируем данные сразу
– Поддержка JSONB → можно переехать частями
– Сильный SQL → отчёты, джойны, агрегации — на ура
– Надёжность и mature-инструменты для миграций, бэкапов, мониторинга


⚠️ Подводные камни:
– Миграция данных: пришлось писать парсеры и валидаторы
– Пришлось переосмыслить структуру: из “гибкого” хаоса в нормализованную модель
– Команда училась писать SQL и настраивать индексы


✅ Зато теперь:
– Запросы летят
– Данные валидны
– Аналитика возможна
– Рост — без боли


Переход с NoSQL на SQL — это не “откат назад”, это осознанный апгрейд, когда бизнесу нужен контроль, скорость и предсказуемость.

#db

👉 @database_info

Читать полностью…

💣 NULL — тихий саботаж в твоей БД

На первый взгляд, NULL — просто отсутствие значения. Но на практике это частый источник багов, неверных аналитик и проблем в бизнес-логике.

📉 Антипаттерн: беспечное обращение с NULL

Примеры:

SELECT * FROM users WHERE age > 18;  -- Пользователи с age = NULL не попадут

Ты думаешь, что отбираешь всех взрослых, но age = NULL тут "выпадает", ведь NULL > 18 → UNKNOWN.

WHERE col1 = col2  -- Не сработает, если хотя бы одно значение NULL

🙈 Проблема: NULL не равно даже самому себе (NULL != NULL).
📉 Итоги: ошибки в JOIN'ах, WHERE-фильтрах, расчетах.



🛡 Как защититься:

✅ Явно учитывай NULL:

WHERE age > 18 OR age IS NULL  -- если хочешь включить "неизвестный возраст"

✅ Используй COALESCE:

SELECT COALESCE(discount, 0) FROM orders  -- подставим 0, если скидка не указана

✅ Проверяй NULL через IS NULL / IS NOT NULL

✅ Для агрегаций учитывай поведение NULL:

AVG(column)  -- пропустит NULL'ы, но COUNT(column) тоже не посчитает их!

Вывод:
NULL — не "ничего", а "неизвестно".
Пиши запросы так, как будто NULL всегда где-то прячется — и он не на твоей стороне.

Сохрани, чтобы не ловить грабли 💥

#db

👉 @database_info

Читать полностью…

🚀 Подборка Telegram каналов для программистов

Системное администрирование, DevOps 📌

/channel/bash_srv Bash Советы
/channel/win_sysadmin Системный Администратор Windows
/channel/sysadmin_girl Девочка Сисадмин
/channel/srv_admin_linux Админские угодья
/channel/linux_srv Типичный Сисадмин
/channel/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
/channel/linux_odmin Linux: Системный администратор
/channel/devops_star DevOps Star (Звезда Девопса)
/channel/i_linux Системный администратор
/channel/linuxchmod Linux
/channel/sys_adminos Системный Администратор
/channel/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
/channel/sysadminof Книги для админов, полезные материалы
/channel/i_odmin Все для системного администратора
/channel/i_odmin_book Библиотека Системного Администратора
/channel/i_odmin_chat Чат системных администраторов
/channel/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
/channel/sysadminoff Новости Линукс Linux

1C разработка 📌
/channel/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
/channel/DevLab1C 1С:Предприятие 8
/channel/razrab_1C 1C Разработчик
/channel/buh1C_prog 1C Программист | Бухгалтерия и Учёт
/channel/rabota1C_rus Вакансии для программистов 1С

Программирование C++📌
/channel/cpp_lib Библиотека C/C++ разработчика
/channel/cpp_knigi Книги для программистов C/C++
/channel/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
/channel/pythonofff Python академия.
/channel/BookPython Библиотека Python разработчика
/channel/python_real Python подборки на русском и английском
/channel/python_360 Книги по Python

Java разработка 📌
/channel/BookJava Библиотека Java разработчика
/channel/java_360 Книги по Java Rus
/channel/java_geek Учим Java на примерах

GitHub Сообщество 📌
/channel/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
/channel/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
/channel/developer_mobila Мобильная разработка
/channel/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
/channel/frontend_1 Подборки для frontend разработчиков
/channel/frontend_sovet Frontend советы, примеры и практика!
/channel/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
/channel/game_devv Все о разработке игр

Библиотеки 📌
/channel/book_for_dev Книги для программистов Rus
/channel/programmist_of Книги по программированию
/channel/proglb Библиотека программиста
/channel/bfbook Книги для программистов

БигДата, машинное обучение 📌
/channel/bigdata_1 Big Data, Machine Learning

Программирование 📌
/channel/bookflow Лекции, видеоуроки, доклады с IT конференций
/channel/rust_lib Полезный контент по программированию на Rust
/channel/golang_lib Библиотека Go (Golang) разработчика
/channel/itmozg Программисты, дизайнеры, новости из мира IT
/channel/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
/channel/nodejs_lib Подборки по Node js и все что с ним связано
/channel/ruby_lib Библиотека Ruby программиста
/channel/lifeproger Жизнь программиста. Авторский канал.

QA, тестирование 📌
/channel/testlab_qa Библиотека тестировщика

Шутки программистов 📌
/channel/itumor Шутки программистов

Защита, взлом, безопасность 📌
/channel/thehaking Канал о кибербезопасности
/channel/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
/channel/ux_web Статьи, книги для дизайнеров

Математика 📌
/channel/Pomatematike Канал по математике
/channel/phis_mat Обучающие видео, книги по Физике и Математике
/channel/matgeoru Математика | Геометрия | Логика

Excel лайфхак📌
/channel/Excel_lifehack

/channel/mir_teh Мир технологий (Technology World)

Вакансии 📌
/channel/sysadmin_rabota Системный Администратор
/channel/progjob Вакансии в IT

Читать полностью…

🔗 Мини-гайд по JOIN-ам в SQL

JOIN — мощнейший инструмент в арсенале SQL. Но многие путаются в типах. Разбираем на пальцах:


🔸 INNER JOIN

Что делает: оставляет только совпадающие строки из обеих таблиц.
Когда использовать: когда нужны только те записи, у которых есть соответствие.

SELECT *
FROM orders o
INNER JOIN customers c ON o.customer_id = c.id;

🧠 Best practice: это дефолтный выбор. Работает быстрее, т.к. отбрасывает всё "лишнее".


🔸 LEFT JOIN

Что делает: возвращает все строки из левой таблицы и NULL из правой, если нет совпадения.
Когда использовать: когда нужно сохранить всё из первой таблицы, даже если во второй нет данных.

SELECT *
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id;

🧠 Часто используется для аналитики: "у каких клиентов не было заказов?"


🔸 RIGHT JOIN

Что делает: наоборот — всё из правой таблицы и NULL из левой, если нет совпадения.
Когда использовать: аналогично LEFT JOIN, но редко встречается, потому что просто меняем порядок таблиц.


🔸 FULL OUTER JOIN

Что делает: объединяет LEFT и RIGHT — берёт всё из обеих таблиц.
Когда использовать: когда важны все данные, даже без соответствий.

SELECT *
FROM table_a
FULL OUTER JOIN table_b ON table_a.id = table_b.id;

🧠 Подходит для reconciliation'а или сверки.


❗ Совет

Фильтры (WHERE) после LEFT JOIN могут не дать ожидаемый результат.
Используй ON для условий соединения, WHERE — для фильтрации результата.

Сохрани, чтобы не забыть. А ты какой JOIN используешь чаще всего?

#db

👉 @database_info

Читать полностью…

🎯 Мини-гайд: как НЕ спроектировать монстра вместо схемы БД

Когда проект только начинается, есть соблазн «не заморачиваться» и сделать одну большую таблицу на всё.
Спойлер: потом будет больно.

Вот как этого избежать 👇

1. Начинай с нормализации
– Смотри, какие поля повторяются.
– Разделяй по сущностям: клиент ≠ заказ ≠ товар.
– Нормальные формы — не академикам, а тебе на пользу.

2. Определи связи заранее
– Один ко многим? Многие ко многим?
– Используй FOREIGN KEY, чтобы база помогала тебе, а не мешала.

3. Не бойся JOIN-ов
– Да, их становится больше.
– Но это лучше, чем сотни NULL - ов и "status_1", "status_2" в одной колонке.

4. Планируй под рост
– Временные костыли становятся постоянными.
– Заложи масштабируемость: разнос сущностей, отдельные таблицы для логов, истории, связей.

5. Назначь ID-шки как бог велел
– PRIMARY KEY + автоинкремент или UUID.
– Не делай email или name ключом — это путь в баги.


🧠 Помни: хорошо спроектированная схема ускоряет разработку, а не тормозит её.
А переделывать схему сложнее, чем сделать нормально с самого начала.

💬 Как ты подходишь к проектированию схемы?

#db

👉 @database_info

Читать полностью…

📕MySQL для администраторов, разработчиков, архитекторов и специалистов баз данных

Как грамотно оптимизировать производительность в MySQL и решить возникающие проблемы.

📗 На вебинаре 6 мая в 19:00 разберём:
1. Практические методы оптимизации производительности, диагностику нагрузки и анализ "узких мест" MySQL;
2. Оптимизацию запросов: от простых до сложных.

📘 В результате будете знать всё о настройке ключевых параметров конфигурации, уметь самостоятельно диагностировать и решать проблемы производительности MySQL.

👉 Регистрация и подробности о курсе Базы данных: https://vk.cc/cLzQgf

Все участники открытого урока получат скидку на курс

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Читать полностью…

🔎 Мини-гайд: Индексы в PostgreSQL — быстро и по делу

Индексы — главный инструмент для ускорения запросов. Но неправильное использование может только навредить.

Основные типы индексов в PostgreSQL:
- B-tree — по умолчанию. Идеален для поиска по равенству и диапазону (=, <, >, BETWEEN).
- Hash — только для поиска по точному равенству (=). Становится актуальным реже.
- GIN — для массивов, JSONB, полнотекстового поиска.
- GiST — геоданные, поиск по диапазонам, сложные типы.
- BRIN — для очень больших таблиц с упорядоченными данными (например, логи).

Практические советы:
- Не злоупотребляй индексами: каждый индекс замедляет INSERT/UPDATE/DELETE.
- Следи за актуальностью: периодически проверяй и удаляй неиспользуемые (pg_stat_user_indexes поможет).
- Составные индексы ((col1, col2)) эффективны, только если условия WHERE учитывают порядок колонок.
- Используй EXPLAIN ANALYZE, чтобы понять, работает ли индекс в реальности.

Типичная ошибка:
Создать индекс на всё подряд без анализа запросов. Итог — тормоза на записи и огромный размер базы.

✅ Индексы — это как специи: мало — пресно, много — несъедобно.


Вывод:
Хотите быструю базу — планируйте индексацию так же внимательно, как сами запросы.

Сохрани, чтобы не забыть!

#db

👉 @database_info

Читать полностью…

🚀 Подборка Telegram каналов для программистов

Системное администрирование, DevOps 📌

/channel/bash_srv Bash Советы
/channel/win_sysadmin Системный Администратор Windows
/channel/sysadmin_girl Девочка Сисадмин
/channel/srv_admin_linux Админские угодья
/channel/linux_srv Типичный Сисадмин
/channel/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
/channel/linux_odmin Linux: Системный администратор
/channel/devops_star DevOps Star (Звезда Девопса)
/channel/i_linux Системный администратор
/channel/linuxchmod Linux
/channel/sys_adminos Системный Администратор
/channel/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
/channel/sysadminof Книги для админов, полезные материалы
/channel/i_odmin Все для системного администратора
/channel/i_odmin_book Библиотека Системного Администратора
/channel/i_odmin_chat Чат системных администраторов
/channel/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
/channel/sysadminoff Новости Линукс Linux

1C разработка 📌
/channel/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
/channel/DevLab1C 1С:Предприятие 8
/channel/razrab_1C 1C Разработчик
/channel/buh1C_prog 1C Программист | Бухгалтерия и Учёт
/channel/rabota1C_rus Вакансии для программистов 1С

Программирование C++📌
/channel/cpp_lib Библиотека C/C++ разработчика
/channel/cpp_knigi Книги для программистов C/C++
/channel/cpp_geek Учим C/C++ на примерах

Программирование Python 📌
/channel/pythonofff Python академия.
/channel/BookPython Библиотека Python разработчика
/channel/python_real Python подборки на русском и английском
/channel/python_360 Книги по Python

Java разработка 📌
/channel/BookJava Библиотека Java разработчика
/channel/java_360 Книги по Java Rus
/channel/java_geek Учим Java на примерах

GitHub Сообщество 📌
/channel/Githublib Интересное из GitHub

Базы данных (Data Base) 📌
/channel/database_info Все про базы данных

Мобильная разработка: iOS, Android 📌
/channel/developer_mobila Мобильная разработка
/channel/kotlin_lib Подборки полезного материала по Kotlin

Фронтенд разработка 📌
/channel/frontend_1 Подборки для frontend разработчиков
/channel/frontend_sovet Frontend советы, примеры и практика!
/channel/React_lib Подборки по React js и все что с ним связано

Разработка игр 📌
/channel/game_devv Все о разработке игр

Библиотеки 📌
/channel/book_for_dev Книги для программистов Rus
/channel/programmist_of Книги по программированию
/channel/proglb Библиотека программиста
/channel/bfbook Книги для программистов

БигДата, машинное обучение 📌
/channel/bigdata_1 Big Data, Machine Learning

Программирование 📌
/channel/bookflow Лекции, видеоуроки, доклады с IT конференций
/channel/rust_lib Полезный контент по программированию на Rust
/channel/golang_lib Библиотека Go (Golang) разработчика
/channel/itmozg Программисты, дизайнеры, новости из мира IT
/channel/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻
/channel/nodejs_lib Подборки по Node js и все что с ним связано
/channel/ruby_lib Библиотека Ruby программиста
/channel/lifeproger Жизнь программиста. Авторский канал.

QA, тестирование 📌
/channel/testlab_qa Библиотека тестировщика

Шутки программистов 📌
/channel/itumor Шутки программистов

Защита, взлом, безопасность 📌
/channel/thehaking Канал о кибербезопасности
/channel/xakep_2 Хакер Free

Книги, статьи для дизайнеров 📌
/channel/ux_web Статьи, книги для дизайнеров

Математика 📌
/channel/Pomatematike Канал по математике
/channel/phis_mat Обучающие видео, книги по Физике и Математике
/channel/matgeoru Математика | Геометрия | Логика

Excel лайфхак📌
/channel/Excel_lifehack

/channel/mir_teh Мир технологий (Technology World)

Вакансии 📌
/channel/sysadmin_rabota Системный Администратор
/channel/progjob Вакансии в IT

Читать полностью…

🚨 Как понять, почему запрос тормозит?

Сегодня покажу простой, но действенный подход к диагностике медленных SQL-запросов. Когда к тебе приходит прод с жалобой "что-то всё виснет", важно не паниковать, а системно подойти к анализу.

Вот что я делаю первым делом:

1. Включаю EXPLAIN (ANALYZE)
Это ваш лучший друг. Не EXPLAIN, а именно ANALYZE, чтобы получить реальные значения времени, а не план на бумаге.

2. Смотрю на узлы с наибольшим временем
Часто виновник — Seq Scan по большой таблице или Nested Loop с миллионами итераций.

3. Ищу несработавшие индексы
Был ли Index Scan или Index Only Scan? Если нет — стоит проверить, почему не сработал индекс. Может, фильтр не селективный?

4. Проверяю фильтрацию и сортировку
ORDER BY может убить всё. Особенно если не по индексу.

5. Думаю про статистику
ANALYZE делали недавно? PostgreSQL может строить плохой план, если у него устаревшие данные.


🛠 Если ты часто отлаживаешь SQL — советую поставить pgMustard или использовать EXPLAIN DEPOT. Они визуализируют планы и сразу показывают узкие места.

💬 Расскажи, как ты ищешь узкие места в запросах? Есть свой лайфхак?

#db

👉 @database_info

Читать полностью…

📕Открытый урок о NoSQL с Cassandra для разработчиков, администраторов, специалистов по базам данных, Data engineers, Backend и FullStack-разработчиков.

На открытом уроке 21 апреля в 20:00 мск мы погрузимся в тонкости работы c NoSQL в Cassandra.

📗В результате вы:
- Узнаете, как работает Cassandra и какие есть особенности про которые никто говорит;
- Разберетесь, как избежать и решать проблемы в работе Сassandra;
- Освоите техники и лайфхаки в Сassandra на практике.

Спикер Дмитрий Гурьянов — Team Lead команды разработки CRM-решений на платформе .NET в Промсвязьбанке, 9+ лет в разработке, работал в Microsoft над продуктом Bing, аспирант кафедры "Системы обработки информации и управления" в МГТУ им. Н.Э. Баумана.

👉Регистрируйтесь прямо сейчас, чтобы не пропустить мероприятие: https://vk.cc/cKWZYo

📙Все участники открытого урока получат скидку на курс "Базы данных"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Читать полностью…

🚀 Data Engineer в Navio: получи оффер в компанию за 1 день!

В команду BigData мы ищем специалистов уровней middle и senior, готовых решать нестандартные задачи и создавать проекты, которые меняют мир. Наши данные имеют физический смысл: победа над каждой ошибкой здесь — снижение риска ДТП в реальном мире.

С нами ты будешь: собирать датасеты для нейросетей, обрабатывать данные для работы автономных машин, визуализировать 4D-траектории, строить системы для сквозной аналитики и не только.

Готов проявить свои навыки? Заполняй заявку, оставляй резюме на сайте и получи приглашение от нашего рекрутера на One Day Offer 26 апреля. Приходи на онлайн-мероприятие, пообщайся с командой и, возможно, уже вечером ты станешь ее частью.

⚡️ One Day Offer — твой шанс изменить карьеру!

Читать полностью…

⚠️ Антипаттерн: использовать NULL без оглядки

На первый взгляд NULL — это просто “нет значения”. Но в реальности — это тихий саботаж:

🔸 NULL != NULL. Да-да, сравнение NULL = NULL даст false или unknown. Это ломает привычную логику и может убить фильтры.

🔸 Агрегации ведут себя странно. COUNT(column) не считает NULL'ы. AVG, SUM — тоже их игнорируют. Итог: неверная статистика.

🔸 Индексы и WHERE column IS NULL. Не все СУБД эффективно используют индексы при таких запросах. Можно словить тормоза.

🔸 NOT IN + NULL = 💥. Запрос WHERE id NOT IN (subquery) может вернуть пустой результат, если в подзапросе есть хотя бы один NULL.

💡 Как избежать проблем:

1. Всегда осознанно работай с NULL — используй IS NULL и IS NOT NULL, не = и !=.
2. По возможности избегай NULL в колонках, где это не нужно. Лучше использовать значения по умолчанию.
3. Добавляй проверки в коде: COALESCE, IFNULL, NVL и аналоги.
4. Понимай, как твоя СУБД работает с NULL в индексах и фильтрах.

🎯 Вывод: NULL — не пустота, а “неизвестность”. Обращайся с ним осторожно, иначе баги будут неявными и неприятными.

Сохрани, чтобы не отловить баг на проде 🐛

#db

👉 @database_info

Читать полностью…

🧵 Сегодня я покажу вам простой, но мощный способ отладки сложных SQL-запросов

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

💡 Суть: разбиваем запрос на небольшие части и поочередно проверяем каждую

Вот как это делаю я:

1. Начинаю с ядра — самого внутреннего подзапроса или CTE. Проверяю, что он возвращает ожидаемые данные.
2. Добавляю следующий уровень логики — джойны, условия, группировки. Каждый раз выполняю и проверяю результат.
3. Для удобства использую WITH (CTE) — это даёт имена промежуточным результатам и делает запрос читабельным.
4. Сложные выражения и агрегаты выношу в отдельные CTE — это помогает быстрее изолировать проблему.
5. Если запрос очень тяжёлый — сохраняю промежуточные результаты в временные таблицы.

🔥 PostgreSQL позволяет использовать EXPLAIN (ANALYZE, BUFFERS) для профилирования на каждом этапе. Очень помогает найти, где тормозит.

Если хотите, могу на неделе разобрать один такой "тяжёлый" запрос от подписчика. Скиньте в комменты 👇

#db

👉 @database_info

Читать полностью…

⌨️ Типы баз данных

#bd #ten

Это перевод / адаптация оригинальной статьи
Если понравился пост и считаешь, что я не зря потрудился — ставь реакцию
Показался полезным — добавляй в избранное
Подписывайся на канал DevOps // Human Help

Читать полностью…