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

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

💣 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

⚡️ Индексы в базах данных: как заставить запросы летать

Представь, что тебе нужно найти нужную главу в техническом справочнике на 1000 страниц. Без оглавления придется листать всё подряд (в базах данных это называется Full Table Scan - страшный сон любого админа). Индекс - это и есть то самое оглавление.

Как это работает под капотом?
Чаще всего индексы строятся на основе B-деревьев (B-Tree) или хэш-таблиц. Суть в том, что БД создает отдельную компактную структуру данных, где значения нужной колонки заранее отсортированы, а рядом лежат быстрые указатели на физическое расположение строк на диске.

✅ Зачем нужны:

* Скорость поиска (SELECT с условием WHERE) возрастает в сотни раз.
* Мгновенно ускоряются операции сортировки (ORDER BY) и связывания таблиц (JOIN).

❌ Чем платим (минусы):

* Тормоза при записи: при каждом INSERT, UPDATE или DELETE базе приходится перестраивать индекс.
* Место на диске: индексы хранятся на диске и съедают оперативную память (RAM). Иногда массивные индексы весят больше, чем сами данные таблицы.

🛠 Чек-лист: индексировать или нет?

🟢 Обязательно индексируем:

1. Колонки, которые постоянно светятся в WHERE, JOIN, ORDER BY, GROUP BY.
2. Внешние ключи (Foreign Keys). Первичные (Primary Keys) СУБД индексирует автоматически.
3. Столбцы с высокой уникальностью значений (ID пользователей, email, артикулы).

🔴 НЕ индексируем:

1. Крошечные таблицы-справочники (прочитать их целиком быстрее, чем дергать индекс).
2. Колонки с низкой уникальностью значений (например, пол или статус active/inactive - индекс по ним практически бесполезен).
3. Таблицы с интенсивной записью (например, логирование). Индексы там убьют производительность INSERT.

💡Не создавай индексы «на всякий случай». Лови медленные запросы, читай вывод EXPLAIN (или EXPLAIN ANALYZE) и добавляй индексы только там, где они реально решают проблему.

#db

👉 @database_info

🦾 LLM умеют генерировать тексты, отвечать на вопросы и работать с документами. Но чтобы использовать их в реальных задачах, важно понимать, как модели принимают решения и почему иногда дают неожиданный результат.

🚀 На открытом уроке разберём, как устроены большие языковые модели и как применять эти знания на практике. Вы узнаете:

— как модель выбирает слова и формирует ответ;
— как развернуть LLM локально и проверить её работу через API;
— как модели используют контекст из документов и почему это важно для RAG-систем.

Урок подойдет начинающим разработчикам, аналитикам и менеджерам продукта, которые хотят понимать ИИ глубже и использовать его в рабочих задачах. Открытый урок проходит в преддверии старта курса «LLM-инженер».

📋 27 октября в 20:00 МСК.
➡️ Все участники получат скидку на обучение. Принять участие: https://vk.cc/d2Romz

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

Антипаттерн: Ненормализованная схема в 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

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

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

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

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

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

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

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

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


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

#db

👉 @database_info

🚀 Подборка полезных 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

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

Когда бизнес-логика усложняется, а структура БД остаётся в духе 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 — быстро и по делу

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

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

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

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

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


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

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

#db

👉 @database_info